Summary in cards format o the architecture styles extrated from the book Software Architecture by Mark Richards, Neal Ford
Layered architecture organizes components into horizontal layers responsible for specific functionalities, like presentation, business logic, and data access. Each layer interacts only with the one below it, promoting separation of concerns and maintainability.
- Separation of concerns
- Maintainability and reusability
- Easier to understand and modify
- Aligns with organizational roles (UI developers, backend developers, etc.)
- Performance overhead due to layer communication
- Rigidity, as changes in one layer can affect others
- Lack of overall agility
- Difficult to apply domain-driven design
- Applications with well-defined functional areas
- When separation of concerns, maintainability, and reusability are priorities
- As a starting point when the final architecture style is not yet determined
- Use open and closed layers to define relationships and request flows.
- Avoid excessive layering, circular dependencies, and skipping layers.
- Beware of the architecture sinkhole anti-pattern, where requests pass through layers without applying business logic.
- Analyze the percentage of requests falling into the sinkhole anti-pattern and use the 80-20 rule to decide if layered architecture is the right choice.
| Characteristics | Rating |
|---|---|
| Partitioning type | Technical |
| Number of quanta | 1 |
| Deployability | 1 |
| Elasticity | 1 |
| Evolutionary | 1 |
| Fault tolerance | 1 |
| Modularity | 1 |
| Overall cost | 5 |
| Performance | 2 |
| Reliability | 3 |
| Scalability | 1 |
| Simplicity | 5 |
| Testability | 2 |
Pipeline architecture organizes components into a series of pipes and filters. In this style, pipes act as the communication channel between filters, while filters perform specific tasks and process data. It is commonly used in Unix terminal shell languages, functional programming languages, and tools utilizing the MapReduce programming model. It is well-suited for simple, one-way processing tasks, and promotes compositional reuse due to the simplicity of pipes and filters.
- Overall cost and simplicity
- Modularity due to separation of concerns between filter types
- Monolithic nature, easier to understand and build
- Limited elasticity and scalability due to monolithic deployment
- Low fault tolerance and availability due to monolithic deployments
- Testability and deployability are average
- Applications that require simple, one-way processing
- When modularity and low cost are main concerns
- Not well-suited for applications requiring high scalability or fault tolerance
- Consists of pipes and filters, where pipes form one-way communication channels between filters, usually in a point-to-point fashion
- Filters can be of four types: Producer, Transformer, Tester, and Consumer, each performing a specific task and processing data independently
- Commonly used in Electronic Data Interchange (EDI) tools, Extract-Transform-Load (ETL) tools, and orchestrators like Apache Camel
| Characteristics | Rating |
|---|---|
| Partitioning type | Technical |
| Number of quanta | 1 |
| Deployability | ⭐️⭐️ |
| Elasticity | ⭐️ |
| Evolutionary | ⭐️⭐️⭐️ |
| Fault tolerance | ⭐️ |
| Modularity | ⭐️⭐️⭐️ |
| Overall cost | ⭐️⭐️⭐️⭐️⭐️ |
| Performance | ⭐️⭐️ |
| Reliability | ⭐️⭐️⭐️ |
| Scalability | ⭐️ |
| Simplicity | ⭐️⭐️⭐️⭐️⭐️ |
| Testability | ⭐️⭐️⭐️ |