Architecture Principles
Answers the Question(s) | Brief Description | edX Example(s) | References (Reading List) | |
---|---|---|---|---|
Domain-Driven Design (DDD) | Where should this code live? Which service/app should be the source of the truth of this data? What should be the boundary (or single responsibility) of this service/app? What should we name "it"? How should we structure our code? How should we keep this service/app isolated from others? What are edX's main business domains and bounded contexts? | DDD provides principles for modeling our system and our code. Eric Evan's original book is hefty and contains many finer points, but the biggest takeaways for edX are:
|
Non-Examples:
| Domain-Driven Design |
Reactive Manifesto (RM) & Self-Contained Systems (SCS) | How can we achieve low latency when responding to end-user requests? How can we scale the communications between services in our architecture? What should be the communication relationship between backend services? What should be the separation of concerns between backend and frontend? | The Reactive Manifesto recommends asynchronous (non-blocking) communication channels between services wherever possible in order to create a scalable loosely coupled architecture. This then results in a system that is responsive, resilient, and elastic. The principles of Self-Contained Systems take the Reactive Manifesto one step further and advocate for highly decoupled verticals in the system, with each vertical owning its own frontends and data. Each SCS is highly cohesive and completely independent of other SCS's. This may lead to data duplication across SCS's, but results in a highly loosely coupled architecture. This is consistent with DDD's recommendation for data ownership within each context. |
Non-Examples:
| |
SOLID | Where should this code live? How do we scale development so volatile changes don't require modifications to a stable core? What should be the design of this API? Should we break up this component/API into multiple parts? How do we create an API suitable for a plugin architecture? | Following SOLID design principles lead to creating a scalable and maintainable codebase where:
|
| Clean Architecture |