Software modules operate against a context. That context may be the rendering of windows, the construction of HTTP responses, database persistence, or the definition of business requirements.
The context of the problem in which a module is designed as a solution is called the domain. All applicable contexts of a module are the module’s domain.
For example, the domain of the FastRoute library is routing; deference of a web request to a specific piece of code based on the contents of the request. Included in the domain are HTTP concepts like GET, POST, query strings, etc. In contrast, the domain of an e-commerce system includes concepts like products, categories, discounts, payment methods, etc.
What is Modeling?
Bounded by limited cognitive capabilities, decision-makers resort to using mental models (reduced versions of real world dynamics) for decision-making and interventions in complex tasks. Such mental models are constantly updated with new experience and knowledge acquired, facilitating a learning process. Through this learning process, mental models can be refined to better represent real world dynamics.
Systems theory suggests that updates of mental models happen in continuous cycles involving conceptualization, experimentation, and reflection (C-E-R), which closely resembles a dynamic decision-making process (DDM). source
In the context of software development, modeling is the design and implementation of algorithms as solutions to defined problems. The algorithms are encoded cohesively according to the structure of a mental model.
Cohesion
In computer science, Cohesion is “the degree to which the elements of a module belong together." - Yourdon & Constantine 1979
There are a number of measurements that one could use to determine how the elements of a module belong together.
Cohesion by Model
When you implement a domain model, a core decision-making component is how closely related the concepts are in the model.
The primary benefit of cohesion by model is that we can avoid unintended complexity in designing the software. So long as the software model is compatible with the conceptual model, changes in the domain can be incorporated equivocally into the code.
Domain Modeling
In practice, concepts in a model such as ‘Members’, ‘Posts’, ‘Payments’ and ‘Invoices’ must be persisted. These are elements of the domain model. These concepts are encoded into a programming language in a way that matches their conceptual model as closely and reasonably as possible.
In the object-oriented paradigm, objects directly represent concepts in the model and encapsulate the necessary data and behavior accordingly. The data and behavior related to a member is likely stored in an instance of the Member class, etc.
There are many ways to structure applications. Domain modeling is only one. Domain modeling is about designing software modules around the cohesive structure of the domain.
To contrast with domain modeling, another approach might be to bypass modeling the domain entirely and to instead create procedures that map input directly to output.
When code is not cohesively grouped as a representation of a mental model, changes in the collective mind of the business will not map directly to changes in the code. The link between the structure of the software and the structure of the domain model is lost. Without this link, the divergence between the significance of changes to the model and the necessary changes to the software that result are allowed and encouraged to become disproportionate. In this case, a small model change is more likely to result in a large change to the code.
Bypassing domain modeling is particularly effective when a small amount of code is being written that will not need to be quickly, easily, or frequently changed.