Architectural-Styles
Architectural styles define the framework for software structure and behaviour. These styles guide how components interact, communicate, and are deployed, directly impacting scalability, performance, and maintainability.
Goal
The goal is to select an architectural style that aligns with the project's requirements, enhances the team's ability to deliver features rapidly and reliably, and supports scalability and maintenance.
Context
Different architectural styles have different trade-offs and implications for system performance, scalability, and maintainability. By understanding the available architectural styles, teams can make informed decisions that align with their project's needs and objectives.
Styles
| Style | Description | Benefits | Considerations |
|---|---|---|---|
| Monolithic Architecture | A single, unified code base in which components are interconnected and dependent, simplifying deployment but potentially complicating scalability. | Easier to develop and test | Can cause a blocker due to shared code and shared path to production. |
| Layered Architecture | Divides the software into layers, each with a specific responsibility, promoting reusability and maintainability. | Clear separation of concerns | Can lead to tight coupling between layers. |
| Modular Architecture | organises the system into modules, each with its own functionality, promoting reusability and maintainability. | Easier to maintain and scale | Can lead to complex dependency management. |
| Microservices Architecture | Divides functionality into independent, loosely coupled services, enhancing scalability and enabling continuous deployment and integration. | Promotes flexibility, fault isolation, and independent scaling | Introduces complexity and operational overhead. |
Inputs
| Artifact | Description |
|---|---|
| User Stories | Detailed descriptions of the functionality, performance criteria, and interfaces needed for each component. |
Outputs
| Artifact | Description | Benefits |
|---|---|---|
| Architectural Decision Records | Documents that capture the important architectural decisions made during the development process. | Provides a record of the project's architectural history and rationale. |
Anti-patterns
- Over-Engineering: Introducing unnecessary complexity by adopting an architectural style that exceeds the project's current needs.
- Premature Optimisation: Optimising aspects of the architecture before understanding the actual performance bottlenecks.
- Technology Bias: Selecting an architectural style based on personal preference rather than project requirements and objectives.