A domain model is a structured representation of a problem domain: its concepts, properties, relationships, and behavior. It keeps business meaning visible instead of scattering it across layers of abstraction. section 5.0
Good modeling balances adequacy with simplicity. Excessively abstract designs can obscure requirements and make reasoning difficult; domain-first design keeps essential complexity recognizable and manageable. section 5.0 section 1.3
Common ways to represent a domain include:
- Classes and interfaces, as in object-oriented design, can describe entities, clients, implementations, and supporting enumerations. section 1.3
- Algebraic data types can encode complex structures and business alternatives directly, supporting clearer domain-specific languages. section 5.2 section 5.4
- Embedded domain-specific languages can make domain operations interpretable, while careful grouping and separation of responsibilities limit accidental complexity. section 5.4
- A domain model need not match a database model: persistence may use different structures, with typed layers handling safe conversions. section 11.3
Engine control subsystem
A small engine-control domain can model starting and stopping engines, bookkeeping subsystems, an Engine implementation, a ControlPanel client, an ISubsystem interface, and a Status enumeration. The model communicates responsibilities before implementation details dominate. section 1.3
Figure 1.7 OOD class diagram for the engine control subsystem
Use the class diagram to inspect how a domain model connects interfaces, implementations, clients, and supporting domain values. section 1.3
