Architectural Patterns¶
Architectural patterns provide reusable solutions for structuring back-end systems. Instead of inventing a new structure for every project, you can apply well-known patterns such as layered architecture, hexagonal (ports and adapters) architecture, microservices, or event-driven architectures. These patterns help you design systems that are easier to maintain, test, and evolve as requirements change.
For this product, you choose one or more architectural patterns and describe how you applied them in your project and why they fit your context.
Common Architectural Patterns¶
Examples of architectural patterns that are relevant for back-end developers include:
- Layered architecture (n-tier): separation into layers such as presentation, application/service, domain, and infrastructure
- Hexagonal / Ports and Adapters: isolating the domain from external systems using ports (interfaces) and adapters (implementations)
- Clean architecture / Onion architecture: emphasising dependency rules that point inwards to the core domain
- Microservices & service boundaries: splitting a system into independently deployable services around business capabilities
- Event-driven architecture: using events to decouple components and drive workflows
In your project you may not implement all of these, but you can still adopt the ideas behind them to structure modules, layers, and boundaries in a clear way.
Quality indicators¶
When assessing this product, the following quality indicators will be considered:
- The architectural patterns document is self-contained, with an introduction/context and then a description of the chosen patterns.
- It clearly identifies which architectural pattern(s) are used and why they were chosen for this project.
- It describes how responsibilities are divided across layers, modules, or services.
- It shows how dependencies are organised (for example domain not depending on infrastructure) and how this supports testability and maintainability.
- It includes diagrams or overviews that illustrate the architecture and key flows.
- It includes examples of code or module structure that demonstrate the applied patterns, with references to the code in GitLab.
- It reflects on the benefits and trade-offs of the chosen patterns (complexity, learning curve, flexibility).
- It includes a list of sources used to understand and apply the architectural patterns.
Template¶
To document architectural patterns in your own project, you can use the following template:
# Architectural Patterns
In this section, describe in a few sentences which architectural pattern(s) you use and what problem they solve in your project. This is the main text of your document.
## Context & Requirements
Here you describe the context:
- What the system does
- Which quality attributes are important (for example testability, scalability, modifiability)
- Any constraints (team size, deployment model, technology choices)
## Chosen Patterns
Here you describe the architectural pattern(s) you selected:
- Name and short description of each pattern (for example layered, hexagonal, microservices, event-driven)
- Why these patterns are a good fit for your project
## Structure & Responsibilities
Here you describe how the system is structured:
- Which layers, modules, or services exist
- What responsibilities each part has
- How dependencies are arranged between parts
Add diagrams or tables to make this clear, and references to the code in GitLab.
## Examples in Code
Here you show how the patterns appear in your code:
- Folder/module structure
- Example classes or functions that illustrate the pattern
## Sources
List here the sources you used to understand and apply architectural patterns (documentation, articles, videos, books, etc.).
Also include sources that helped you write the code.