A domain model holds an application’s core business logic: its entities, value objects, domain services, rules, responsibilities, and workflows. It stays independent of external systems and implementation details such as databases and APIs. In hexagonal architecture, it sits at the center, while ports and adapters connect it to the outside world. section 3.3 section 4.1
Treat the model as the place where business rules are applied and enforced. Build it before wiring infrastructure, then use generated code as a starting point: compare variations, understand why they differ, and refine the design rather than accepting an output unchanged. section 4.0
IT asset management model
An IT asset management model can begin with Hardware inheriting from Asset. Asset contains FundingDetails, and a DepreciationStrategy interface allows different depreciation calculations—straight-line, declining-balance, double-declining, or none—to be substituted without changing the asset’s role. section 3.3
Evolve a domain model by making business relationships explicit:
- Add an Asset parent when Hardware needs shared identity, status, category, and funding details. section 3.3
- Replace a simple funding-details field with FundingDetails when that information gains its own responsibilities. section 3.3
- Model alternative depreciation rules behind DepreciationStrategy when calculation behavior must be swappable. section 3.3
Figure 3.5 We have added a depreciation strategy to our object model. This introduction allows us to swap out the method by which we can calculate the depreciation of an asset.
Inspect the strategy-based design to see how a domain model separates an asset’s business data from interchangeable depreciation behavior. section 3.3
