Application Architecture
This section contains a collection of common application architecture patterns. Each pattern is implemented in TypeScript with a concrete example of the concepts in practice.
Application Controller
The Application Controller pattern centralizes navigation logic in one place. It acts as an intermediary between the user interface and the domain logic. When a user takes action, the UI notifies the Application Controller. Then, it checks a set of rules based on the app’s current state. This helps decide which business logic (Domain Command) to run and which view to show next. This pattern is great for apps with complex screen flows, such as wizards.
Front Controller
The Front Controller is a design pattern that processes all requests to a website using a single handler. The handler decodes the URL and extracts request data to determine which command should process the request. This pattern pairs well with the Intercepting Filter (Decorator) pattern.
Intercepting Filter
The Intercepting Filter processes requests and responses before and after the main application logic. It works by defining a chain of filters that handle specific concerns. For example: logging, authentication, input validation, or data transformation. The Filter Manager executes each filter in sequence; This allows for modular and reusable processing steps.
Model View Controller (MVC)
MVC divides an application into three parts, the model, view, and controller.
- Models use the Observer pattern to notify views that data has changed.
- Views use the Composite pattern to create a hierarchy of UI elements.
- Controllers use the Strategy pattern to handle events from views.
Views are always hierarchies, with one single “top view”, and many child views. A single view can represent both single items, such as a checkbox, or more complex components, such as a list of selectable items.
Page Controller
The Page Controller uses a controller for each logical page on a website. It is responsible for decoding the request URL, extracting form data, creating a model, determining which view to display, and forwarding the model to a view to render the page.
Template View
The Template View renders content by embedding “markers” within a static HTML template. These markers get replaced at runtime with data provided by a helper object. The helper encapsulates logic for getting and formatting the related data. This approach separates the presentation layer from the application logic. This way, designers can work on the HTML without needing to write code.
Transform View
The Transform View builds HTML by calling transform functions for each input element. This pattern is different from the Template View, which gets built from the final layout. We apply these transformations in a sequence or loop. The pattern encourages separation of concerns, testability, and logic-focused view layers.
Two-Step View
The Two-Step View pattern renders domain data into HTML in two distinct stages. The first step transforms the data into a uniform, presentation-oriented structure. This structure is free of specific formatting (like HTML). For example, it might include fields or tables that represent the logical layout of a screen. The second step takes the intermediate structure and renders it to HTML.