A domain model represents the core concepts and relationships of a problem domain independently of technical implementation. In a modular Go system, it gives API and worker modules a shared vocabulary while keeping business logic independent of databases, HTTP frameworks, and other infrastructure. section 11.1.2
A practical domain model separates nouns from verbs:
- Entities such as Article and Feed define the system's core data, using portable standard-library types such as time.Time. section 11.1.2
- Interfaces such as Fetcher, ArticleReader, and Storage define required behavior without prescribing implementations. section 11.1.2
- Dependencies point inward: API, worker, storage, and protocol code depend on domain abstractions rather than the domain depending on infrastructure. section 11.1.2 section 11.3.6
RSS system domain
An RSS application can define Article and Feed in a domain package, then expose Fetcher for retrieving feeds and Storage for persisting articles. The API and background worker consume these contracts while choosing their own HTTP, parsing, or persistence implementations. section 11.1.2 section 11.3.6
Figure 11.3 Domain-driven design separates core logic from infrastructure.
Use the architecture diagram to trace the domain at the center and the one-way relationships between core logic, ports, adapters, API, and worker modules. section 11.1.2
