Architecture Patterns

Overview

Suppose an order screen has a quantity field whose change handler parses the input as a number, fills an error label if it exceeds stock, and otherwise calculates the total, updates its label and enables the order button. The button's click handler checks stock again, then saves the order to a database. Even checking the single rule "an order cannot exceed available stock" requires opening a window, connecting a database and entering a quantity. Input interpretation, screen updates, business rules and persistence are mixed into two handlers, so none can run or change on its own. An order screen makes a useful example because one input leads through validation, calculation, display and saving, letting us compare the responsibilities that need to be separated within one situation.

In this document, architecture patterns name ways to divide this code at the screen or application level. Each pattern defines the roles, the route user input and screen updates take through those roles, and the direction of source-code dependencies. The GoF design patterns introduced in Programming Patterns have a smaller scope: they describe how objects are created, assembled and made to cooperate. The two levels work together. In MVC, for example, the model notifies views of changes through the Observer pattern.

Architecture patterns address two kinds of questions. The division of input, presentation and presentation rules within a screen is the subject of UI architecture patterns such as MVC, MVP, MVVM and MVU, each covered in its own article. Boundaries and dependencies between business rules and external technologies such as databases, web frameworks and external services are the subject of application structure patterns. Layered, hexagonal, onion and clean architecture receive a brief introduction here. In the order screen above, separating the stock rule from its handler addresses the first question; preventing that rule from directly calling database code addresses the second.

The two kinds overlap within a program. In his article on clean architecture, Robert C. Martin places the GUI's entire MVC structure in the interface adapters layer, the third concentric circle from the inside.¹

Comparing UI architecture patterns

All four patterns separate screen code from other logic so that some of it can be tested without opening a window, but the testable part differs. They also differ in who receives user input first and how changed values reach the screen.

When reading the table and diagrams, follow who first receives user input, who changes state, and who transfers changed values to the screen. Displaying a total after a quantity change, for example, requires both interpreting the input and applying the new total to the screen. The comparison below follows the roles involved in these two stages. The individual articles use counters, searches and carts to expose each flow on a small scale; the table does not compare four executions of the same ordering program.

The figure contains four UML communication diagrams. Each panel numbers the messages from one user input through the resulting screen update. Dots indicate nested calls: 1.1.2 is the second message sent while handling 1.1. Participant names come from the examples in the individual pattern articles; Button, TextBlock, BindingExpression (WPF) and Html (Elm) are framework types. The MVVM panel shows a binding engine such as WPF's, rather than the example's console Binder. As a command source, the button directly calls the bound command's Execute;² binding (BindingExpression) appears only when it receives PropertyChanged and updates a displayed value. In the MVU panel, Render(html) names the runtime step that applies the new screen. Class and sequence diagrams appear in each pattern's article.

MVC and MVVM both update the screen through change notifications, but different recipients handle them. In Smalltalk-80 MVC, a view registers as a dependent of the model and receives an update message when the model changes.³ In MVVM, the binding engine receives the ViewModel's PropertyChanged notification and updates the view.⁴ MVP's Passive View updates through explicit presenter calls, so the view and model have no dependency in either direction.⁵ In MVU, messages go to update to calculate a new model instead of subscribing to model-property changes. Update is the sole route for state changes, and the view function recalculates the screen whenever a new model arrives.⁶

History

This timeline combines the histories from the four UI pattern articles with the main publications on application structure, in chronological order. Links in the source column support each row.

MVP and MVVM arose by adapting or specializing earlier patterns. Potel introduced MVP as a programming model that generalized Smalltalk MVC, and described the presenter as lifting the classical Smalltalk controller's responsibilities to the application level.⁷ The Dolphin Smalltalk team found that MVC connected an application model and its views only indirectly, while native Windows controls already supplied most controller behavior. The team adopted Taligent's MVP after a colleague introduced it.⁸ Fowler wrote that VisualWorks Smalltalk users knew Presentation Model as Application Model. In a later note, he said the pattern was increasingly known as MVVM.⁹ Gossman described MVVM as a variation of MVC for environments in which designers build views in declarative languages such as XAML,¹⁰ while Smith treated it as a specialization of Presentation Model for WPF and Silverlight.¹¹ On the MVU side, the Redux documentation says Elm's updater has the same role as Redux's reducer,¹² and the Elm guide notes that The Elm Architecture inspired projects such as Redux.⁶

Application structure patterns also refer to one another. Palermo wrote that hexagonal and onion architecture share the premise of moving infrastructure to the outside and using adapter code to avoid tight coupling to it.¹³ Martin's 2012 article lists hexagonal, onion and other architectures, explaining that although their details differ, they share the aim of separating concerns by dividing software into layers.¹

Application structure patterns

The following four patterns divide an entire application, beyond a single screen. All ask whether business rules, or the domain, depend on external technologies such as databases, web frameworks and UI.

Moving total calculation out of the order screen's button handler makes it easier to test without a window. But if the extracted code must call a real database whenever it checks stock, that check still requires a database after the screen is separated. The scope now widens to how business rules connect to persistence technology. Instead of introducing more ordering code, the following sections compare where layers and interfaces sit and which parts reference which.

Layered architecture

Layered architecture divides a program into layers such as presentation (UI), domain logic and data access. In Fowler's account, dependencies generally flow downward: presentation depends on the domain, which depends on the data source. He identifies the main benefit as reducing the scope of attention, since these three subjects can be considered relatively separately. He adds that a variation placing a mapper between the domain and data source, so the domain does not depend on the source, is often called hexagonal architecture.¹⁴ His 2002 book Patterns of Enterprise Application Architecture also treats dividing enterprise applications into layers as a main subject.¹⁵

Hexagonal architecture (ports and adapters)

Alistair Cockburn's Ports and Adapters pattern, also called Hexagonal Architecture, aims to let users, other programs, automated tests and batch scripts drive an application in the same way, and to let development and testing proceed without real devices or databases. The application communicates with the outside through a port, an API defined around the purpose of the conversation. Each external device has an adapter that translates between this API and the device's signals. The application does not know the nature of its input device, and Cockburn requires code that belongs inside to stay inside. He described the pattern as a specific use of the Adapter pattern.¹⁶

Onion architecture

Jeffrey Palermo proposed Onion Architecture in a 2008 series. The domain model sits at the center, repository interfaces for storing and retrieving objects occupy the next layer (Repository pattern), and UI, infrastructure and tests sit at the outside. Code may depend only on layers farther inward, never on outer layers; all coupling points toward the center.¹³ Palermo used this direction to distinguish it from traditional layering, where each layer couples to the one below and to infrastructure. He identified inner layers defining interfaces and outer layers implementing them as a main principle.¹³¹⁷

Clean architecture

Robert C. Martin's 2012 article "The Clean Architecture" presented a diagram intended to combine hexagonal, onion and other architectures into one actionable idea. From the inside outward, its concentric circles contain entities, use cases, interface adapters, and frameworks and drivers. The Dependency Rule allows source-code dependencies to point only inward. When a use case must pass results to an outer presenter, it calls an interface, or output port, defined in an inner circle and implemented by the presenter, making the dependency point against the flow of control.¹ A book with the same title was published by Prentice Hall in 2017.¹⁸

Choosing a pattern

The UI technology often guides the choice. Frameworks built around data binding, such as WPF, tend to provide tools that support MVVM,¹⁹ while Elm's standard browser-program API provides a structure connecting model, view and update.¹² The table suggests which article to read first when a problem appears.

Signs of overuse

• Adding MVVM to a form with two input fields and creating a ViewModel, command classes and binding configuration for it. Gossman also wrote that MVVM may be excessive for simple UI.²⁰

• Creating a view interface, view implementation and presenter for every screen, even when there are few presentation rules. Esposito wrote that MVP increases application-code complexity.²¹

• Splitting a screen with one input and one output into model, view and controller classes.

• Creating message types and a runtime loop for a screen with almost no state.

• Building all four layers of entities, use cases, interface adapters and frameworks for a program with a few CRUD screens. Palermo said onion architecture was not suitable for small websites,¹³ and Martin wrote that there need not be exactly four circles.¹

• Adding several layers of ports and adapters in front of persistence to support replacing a database that no one plans to replace. Fowler wrote that switching data-access mechanisms is often given as a reason to separate the data layer, but he rarely hears of it actually happening.¹⁴

See also

• MVC Pattern

• MVP Pattern

• MVVM Pattern

• MVU Pattern

• Programming Patterns

• Observer pattern

• Adapter pattern

• Repository pattern