Software architect
Straight to the self-checkThe horizon changes: you answer not for your own module but for the system as a whole and for whether it can still be changed long after it was designed.
Do now
- I write the choice of architectural style down together with its priceI can explain why a modular monolith belongs here rather than microservices.
- I draw the boundaries along the domain and test them against the language of the businessMy modules line up with the way the customer talks about their own work.
- I name the places where consistency is not immediate and what the user sees at that momentI know where the data diverges, and it is written down rather than assumed.
- I come back into the code of my own system regularlyI read and change what I designed instead of only drawing diagrams.
Where next
Sideways out of the role
- Backend developer back
- Team lead, tech lead, engineering manager sideways
- SRE and platform engineering sideways
What this step asks of you
I choose an architectural style to fit the problem and know its price
I can explain why a modular monolith belongs here rather than microservices.I record decisions so that they can be revisited
Every major choice has an ADR with the context and the conditions for revisiting it.I draw the boundaries along the domain, not along the layers of code
My modules line up with the way the business thinks about its own work.I understand what being distributed does to data
I know where we have eventual consistency and what the user sees at that moment.
Common mistakes
- Designing by fashion: microservices adopted without need come to the team along with distributed failures.
- Drifting away from the code: the diagrams stop matching the system, and that comes out during an incident.
- Leaving a decision with no conditions for revisiting it: it gets overturned silently and nobody remembers why.
What to learn
- Designing systemsArchitecture patternsDomain-Driven DesignDistributed systems