09: Attribute-Driven Design

Resource Collection: C4 Model Go to related resources.

Resource Collection: Attribute-Driven Design Go to related resources.

Theory: Attribute-Driven Design 3.0

In the previous exercise, we created a C4 System Context diagram, which represents our system as a single black box. At this point, this representation accurately reflects reality: although we have already chosen an architectural style, we still have no concrete idea about the smaller components that make up the system.

Now, however, it is time to “zoom in” on the system and begin breaking it down into smaller parts and refining it.

The method known as Attribute-Driven Design (ADD), a structured, iterative design process, serves this purpose of decomposition and refinement.

The principle of the method is extremely simple: starting from the significant requirements and an existing architecture (which could be just a single box, or the entire system), we iteratively refine until the resulting architecture meets the requirements.

Something like this (feel free to zoom in on the page!):

flowchart TB subgraph DRIVERS[ ] direction LR DP[Design purpose] PFR[Primary functional requirements] QAS[Quality attribute scenarios] CON[Constraints] AC[Architectural concerns] end S1[Step 1: Review inputs] S2[Step 2: Establish iteration goal] S3[Step 3: Refine system elements] S4[Step 4: Choose design concepts] S5[Step 5: Instantiate architecture] S6[Step 6: Sketch views and decisions] S7[Step 7: Analyze current design] OUT([Refined Software Architecture Design]) S1 --> S2 --> S3 --> S4 --> S5 --> S6 --> S7 --> OUT DP -.-> S1 PFR -.-> S1 QAS -.-> S1 CON -.-> S1 AC -.-> S1 EX[From previous rounds or existing system] EX -.-> S1 classDef driver fill:#b71c1c,stroke:#222,color:#fff,stroke-width:2px; classDef step fill:#a9b7e8,stroke:#222,color:#fff,stroke-width:2px; classDef output fill:#dfe8d6,stroke:#222,color:#222,stroke-width:2px; classDef note fill:transparent,stroke:transparent,color:#222; class DP,PFR,QAS,CON,AC driver; class S1,S2,S3,S4,S5,S6,S7 step; class OUT output; class EX note; style DRIVERS fill:transparent,stroke:transparent

Theory: C4 Containers

The C4 model is a hierarchical system of concepts and diagrams.

Following the entire system, the next concept in the hierarchy is the container, which can be, among other things:

a server-side web application,
a server-side service,
a client-side web application,
desktop software,
mobile application,
serverless function,
database,
and so on!

The container diagram is used to represent containers; similar to the system context diagram, there will be only one of these: the entire system, broken down into containers.

Together: ChocoMarket Container Diagram

Let's create a C4 Container Diagram for the ChocoMarket case study!

Note that while the System Context diagram could be created solely based on the SRS (by taking users, user groups, and external dependencies), creating the Container diagram requires us to make architectural decisions.

That is, while creating the Container diagram, it is worth writing ADRs as well, which we can then reference in the diagram.

Architectural decisions relevant to the ChocoMarket Container diagram:

Hybrid architectural style.
EDA for loading catalogs, modular monolith for serving catalogs.
A single database for storing all data.
Writing scanned chocolates to the database via a single writer service.
Separate frontends for different user groups.

ChocoMarket Container Diagram Go to the diagram's source code.

LikeC4 documentation Go to the LikeC4 documentation.

Group Work: Container Diagram

Let's create a C4 Container diagram for our case study!

Homework

Extend the existing C4 System Context diagram in LikeC4 format with a C4 Container diagram view.

The diagram must remain in the group's GitHub repository, as follows:

Directoryadr
- 01-architecture-style.md
ac.md
as.md
asr.md
diagram.likec4
esettanulmany.md
README.md
srs.doc

Document the most important decisions in the form of ADRs!