The summary covers software architecture patterns, not software design patterns.

What are patterns?

Patterns in Software
We encounter patterns on all levels in software

• Solutions to common problems
• Define components and interactions

Design patterns

• Small amount of components
• Part of a larger application
• Example: the factory pattern

Software architecture patterns

• A higher level
• Defines a significant part of the application
• Many components
• Mostly paradigm independent

Why use software architecture patterns?

• Building house with and without the blueprint
• Make code recognizable to other developers
• Easy to find information
• Helps decision-making process

The context of software architecture patterns

Categories of patterns

1. Application landscape patterns
   1. Monolith
   2. N-Tier
   3. Service-oriented
   4. Microservices
   5. Serverless
   6. Peer-to-peer
2. Application structure patterns
   1. Layered
   2. Microkernel
   3. Command query responsibility segregation (CQRS)
   4. Event sourcing
   5. CQRS and event sourcing combined
3. User interface patterns
   1. Model-view-controller (MVC)
   2. Model-view-presenter (MVP)
   3. Model-view-viewmodel (MVVM)

Application landscape patterns

Monolith

An application that consists of a single executable that is deployed as a whole (if there are other components, they are still deployed and executed together).

Pros

• Easy to understand, implement and test
• Easy deployment
• Ideal for limited scope

Cons

• Tight coupling
• Easily leads to complex code
• One size fits all for every subdomain

A monolith is not a synonymous with badly structured code.
It’s perfectly possible to build a clean monolith and let it evolve into other architectural patterns when necessary.

N-Tier

Splits up the application into multiple tiers.
A tier is a piece of the application that is responsible for certain function and that can be physically separated from the other tiers. Tiers are not layers. The responsibilities in a multiple tier application are split up across technical boundaries, not functional ones.

3-Tier

• Presentation tier
• Business logic tier
• Data tier
  These tiers can be installed on the same system, but they can also be on different physical machines.

Usually data flows from one tier to another without skipping tiers.

Pros

• Independent development
• Scalability

Cons

• Changes ripple through tiers: a new filed in a form will require changes in UI, business logic and db.

Service-oriented

Consists of multiple services.
Each service represents a business activity.
Service composability: separate services may consist of other underlying services.
Standardization of data contracts between services and an enterprise service bus which
handles multiple different messaging protocals.

Pros

• Services are loosely coupled
• Scalability
• No duplication of functionality

Cons

• Reduced team agility and team autonomy since it requires central governance
• Costly in terms of money, time and effort
• Many differing views on the definition or concept of this architecture
• The ESB can become a central bottleneck riddled with important business logic

Microservices

Natural evolution of SOA (service-oriented architecture).
Multiple services, each developed, run and maintained by the corresponding team (instead of finishing a part and handing over it to another team).
Each service is a business activity.
Services call each other point to point using a well-known protocol like HTTP, or through a lightweight message broker (in other words, no logic-heavy enterprise service bus).
Maximum automation.
(Services can run in containers to make automated deployment easier).

Pros

• Services are loosely coupled and easily scalable
• Increased agility
• Reliability
• Designed to handle failures (has to handle errors from other services or even messages getting lost)

Cons

• Boundaries not always clear and may change over time
• Communication patterns can become complex

Serverless

Serverless Architectures
TNS Guide to Serverless Technologies: The Best of FaaS and BaaS
BaaS、FaaS、Serverless都是什么馅儿？
Serverless 的喧哗与骚动（一）附Serverless行业发展回顾
serverless到底是个什么鬼

1. Backend as a service
2. Function as a service

Multiple pieces of code called functions which run in short lived containers.
Containers are managed by a third party vendor.

Pros

• Scalability
• Reduce costs
• Easy to experiment functions with new IDs

Cons

• Constraints from the vendor
• Tricky to maintain in memory
• Cold starts

Peer-to-peer

There is no central server.
There is no constant connection (not online all the time).
Dynamically discoverable (might not have fixed URLs or IP addresses).
Ideal for sharing resources like processing power, data, memory or storage.

Pros

• Cost-effective
• Scaling is easy

Cons

• Too decentralized, possible security issues
• Only for specific scenarios
• Nontrivial to code

Application structure patterns

Layered architecture

A layer can call the layer below it but not the one above it.

graph TD
A["Presentation layer (UI)"]
B["Application layer (Translation between UI and business)"]
C["Business layer (Business logic)"]
D["Persistence layer (Code to interact with the database)"]
E["Data layer (Database)"]
A --> B
B --> C
C --> D
D --> E

Pros

• Well-known among mant developers
• Easy to organize

Cons

• Tend to lead monolithic applications
• Need to write a lot of code to merely pass data from one layer to another
• Application is split up across technical boundaries, often difficult to take a specific business functionality and split off into a new application since code is often shared between business domains

Microkernel

Also called plugin pattern.
The application consists of a piece of core logic that can be extended with plugins.
The core defines the contracts that the plugins need to adhere to.

Use cases

• Task scheduler
• Workflow
• Data processing
• Browser extensions
• Graphic design applications

Pros

• Flexibility
• Clean separation
• Separate teams possible
• Add and remove functionality at runtime without restarting the core

Cons

• Core APIs might not be sufficient for future plugins
• Can the plugins be trusted
• Not always clear what belongs in the core

CQRS

Two models: read/query & write/command
Allows for scenario-specific queries (a separate database for queries)
Synchronization of database required

Pros

• Read queries become simpler (need less join statements in SQL)
• Faster and more scalable queries
• Maps better to business language, easier to communicate with stakeholders

Cons

• Added complexity
• Learning Curve
• Learning curve
• Possibility of data inconsistencies
• Eventual consistency (for example UI might not update after the user makes the change)

Event sourcing

深入浅出Event Sourcing和CQRS
深度长文：我对CQRS/EventSourcing架构的思考

Store events instead of current state.
Event = sth that happened in the past.
Rehydration or replay (apply all previous events to a new project).

Pros

• Trace of events
• Audit trail
• Maps greatly to the business language, effective communication
• Event replay to fix bug in the event handler and no need to manually to fix the data

Cons

• Replay and external systems
• Event structure changes
• Too many events lead to slow replay (use snapshots as a starting point for rehydration to improve)
• Learning curve

CQRS combined with event sourcing

Start from event sourcing.
Add CQRS later.

UI patterns

MVVM模式中ViewModel和View、Model有什么区别

MVC

Model: where the data of the application is managed, receives inputs from the Controller
Controller: responsible for receiving user input (relationship between Controller and View?) and passing it to the Model in a way that the Model will understand
View: presenting the model to the user

Pros

• Great for the web: browser sends inputs to the Controllers and receives Views to display to the user
• Clear separation of concerns
• Parallel development
• Popular in web frameworks

Cons

• Controllers can become bloated
• Different definitions

MVP

The user interacts with the view which passes on commands or events to the presenter.
The presenter then manipulates the model and tells the view which data to display where.

1. Passive view: all UI logic in the presenter and the view has no notion of the model
2. Supervising controller: the UI could contain all the necessary details on how to render the model and we would use the presenter for more complex logic (more common)

Pros

• Great for desktop applications
• Separation of concerns
• Testability

Cons

• Presenters can become bloated
• Desktop applications are less popular

MVVM

The Model contains the business logic and data.
The ViewModel interacts with the Model.
Connect the View to the ViewModel by using advanced data binding techniques.
The user interacts with the View.
The user’s interaction are passed on to the ViewModel due to the two way data binding, and any update in the ViewModel is seamlessly passed back to the view.

Pros

• Great for modern desktop and mobile applications
• Separation of concerns
• Testability

Cons

• Overkill for simple user interfaces
• More difficult to debug with the data binding
• Desktop applications are being replaced by web applications using web technology.

Create multiple Views for the same ViewModel?

MVC, MVP and MVVM

MVC、MVP、MVVM，我到底该怎么选？

Differences see the excel table in exercise file

Similarities

• Decoupling view and model
• Extra component in between
• Improving testability (for the intermediate component: Controller, Presenter or ViewModel)

Where to apply

• Web: MVC
• Older desktop applications (with basic data binding): MVP
• Modern desktop and mobile technologies (with advanced data binding): MVVM

Combining patterns

Example1: a monolith that uses the microkernel pattern internally and has an MVP-based UI

Example2: a distributed application landscape with multiple microservices; each service takes their own approach using what’s best for that service: one implements CQRS, another followed a layered architecture, and a MVC application for the user interface