In an earlier story I wrote about Domain Models. Here is a bit more of the “why” we should use domain modelling in software architecture, as a higher priority than other model types such as sequence diagrams, use case diagrams, etc.
Static vs Dynamic Modelling
Domain Modelling is one of the most commonly overlooked parts of software design and software architecture, but it’s also the most important. Domain modelling is one of the static models of software that defines the software structure.
Software design following traditional approaches such as ICONIX focuses on 2 types of modelling:
- Static modelling, such as domain models, class models.
- Dynamic modelling, such as sequence diagrams, use cases, etc.
Static modelling is more important in software design than dynamic modelling. The reason for this is that if we follow a dynamic-first modelling path, then it leads to a build flow as follows:
- The business analysts, stakeholders, etc, agree on requirements.
- Those requirements map to use cases where the actions for each requirement are stated.
- Software designers pick up each use case and map out a function or set of functions that implement those use cases.
- Developers implement each function severally or separately.
… and that that does not lead to an object oriented system.
Static Modelling Path
A static modelling path looks like this:
- The business analysts, stakeholders, etc, agree on requirements.
- The main project terms are extracted from the requirements and put into a Project Glossary.
- The architect maps out a domain model based on the high level nouns contained in the project glossary for those requirements.
- The requirements map to use cases or user stories where the actions for each requirement are stated.
- Software architects or designers map the use cases or user stories to domain model objects based on the data that those use cases manipulate, and if necessary break the domain model objects down into object classes.
- Developers implement each domain model object severally or separately — in a micro-services based system each domain model object may become a separate micro-service.
… which leads to a better, more object oriented system.
The goal of good software design is to produce good software. The goal of good software architecture is to drive and define the software design so that it can only produce good software.