How I design systems now
Here are a few common ways to design a system. None of them fits every case, and most of the time you aren't going to need them.
Event-driven architecture
Order service
Doesn't know who's listening
Event bus
- Inventory
- Billing
- Notifications
- Fits
- One event sets off many independent follow-ups
- Skip it
- The flow is a step or two, and a direct call will do
Domain-driven design
Sales
Customer
A prospect we're talking to
- Translation layer
Billing
Customer
An account that pays
- Translation layer
Support
Customer
A person with a ticket
- Fits
- The business is complex, and teams mean different things by the same word
- Skip it
- It's mostly create, read, update, delete
Explicit architecture
Adapters
- UI
- Database
- Third parties
Application
Domain
All dependencies point inward. The term comes from Herberto Graça.
- Fits
- The business rules will live a long time, and outside dependencies may change
- Skip it
- The project is small, or won't be maintained for long
Distributed system
Client
Load balancer
- Service replica
- Service replica
Service replica
Network cut off
Data
Several copies
- Fits
- One machine really can't cope, or you must span regions
- Skip it
- One machine can still cope
One app, one database
App
Database
- Fits
- Most cases
What's right for your system has to be decided by a domain expert and an experienced system designer like me.