(This is a template with demo data and diagrams. Please copy this and modify accordingly)
Architectural Decision Records (ADRs) are documents designed to capture crucial information about architectural and development process decisions made during the development of software projects. ADRs serve as a systematic and organized way to document the context, considerations, and justifications behind key architectural choices.
Examples:
Choosing a Database Management System
Decision: Adopting PostgreSQL as the primary database management system for the project.
Rationale: Considered factors such as scalability, community support, and compatibility with project requirements.
Selection of Frontend Framework
Decision: Choosing React.js as the frontend framework for the web application.
Rationale: Evaluating various frontend frameworks based on project requirements, maintainability, and developer expertise.
Selection of Backend API System
Decision: Adopting Express.js as the backend API framework for the project.
Rationale: Evaluating backend frameworks based on project requirements, performance considerations, and development speed.
<aside> ⚠️
Defined per system role
</aside>
A flowchart diagram depicts a process, system or computer algorithm. You can consult this page for a short intro about Flowcharts and their basic symbols.
Flowcharts will be used to document and depict Use Cases as a mean that enables a more efficient communication between the implementation team and the stakeholders. After an initial settling of the Use Case flows, they should be depicted in flowcharts in the form: One flowchart per Use Case Scenario.
flowchart TD
A(Play Game) --> B
B[User chooses a Hero to play Game] --> C
C[/User's Hero/]:::purple --> D
D[Backend checks Hero-Game eligibility & Blacklist]:::brown --> E
E{eligible} --> |true| H
E --> |false| G
G(Play Game)
H[Backend transfers Game-data to Client] --> I
I[/Game Data/] --> J
J[User plays game] --> K
K(Game Started)
classDef purple fill:#8470FF
classDef brown fill:#C48B9B
The C4 model defines a set of hierarchical diagrams (1. system context, 2. containers, 3. components, and 4. code) for the Architectural depiction of dependencies between software modules. It is notation and tooling independent and very easy to use and understand.