Domain-driven design organizes software around real-world business concepts instead of technical implementation details. A shared domain module defines stable business logic that API and worker modules can depend on. section 11.1.2
Build the domain boundary around:
- Entities such as Article and Feed, which name the system’s core concepts. section 11.1.2
- Interfaces such as Fetcher, ArticleReader, and Storage, which define required behavior without prescribing implementations. section 11.1.2
- An inward dependency flow: infrastructure and services depend on the domain, while the domain depends on nothing. section 11.1.2
RSS reader domain
An RSS reader can model Article and Feed with standard-library types such as time.Time. Fetcher retrieves feeds, while Storage persists and reads articles. API and worker implementations can change independently because they depend on these domain abstractions rather than concrete databases, HTTP frameworks, or feed parsers. section 11.1.2 section 11.4
Figure 11.4 Hexagonal architecture: Domain at the center with ports and adapters
Use the architecture diagram to trace how the domain stays at the center while ports define boundaries and adapters provide concrete infrastructure integrations. section 11.4
