Domain Model pattern example

Question

I\'m just trying to find some examples of Martin Fowler\'s Domain Model pattern and I can\'t.

From what I found on the Internet Domain Model is just adding some \"logi

Answer 1

Fowler's book that you cite refers to Larman's book for introductory understanding and examples.

Interestingly, Larman's approach to domain modeling doesn't ever add behavior to domain classes.

There is a notion in a domain model that a class is conceptual and is not a software class, but that software classes are based on domain (conceptual) classes. Larman's approach to implementing behavior follows responsibility driven design, and GoF design patterns.

The domain model remains a separate element in the software development process. The good aspect of this way of modeling is you separate the problem from the solution. A domain model is supposed to be true to the problem (capture requirements from the problem domain without addressing implementation details).

Larman presents "operation contracts" as a way to assure behaviors are consistent inside a domain model. Again, contracts are supposed to be independent of a solution (an implementation). Contracts have postconditions that describe a constraint in the domain model after an operation has taken place. An example of a postcondition would be that when a customer completes a purchase in a store, the sale object is associated with each of the items the customer purchased.

The implementation of the business logic should respect the contracts (postconditions) defined for the domain model. Larman's approach with the Controller GRASP pattern as well as other GRASP patterns ends up putting this logic in various classes (usually the domain layer, which is software classes inspired by conceptual classes in the domain model) or Façade (Controller) classes that handle the system operations.

Larman's approach is more complicated than this explanation, but the point is that behavior is never only defined alone in the domain model as methods. Larman says many times that domain (conceptual) classes do not have methods, as they are not software classes.

Fowler's book also refers to another book that he wrote on Analysis Patterns for examples.

The patterns come from various domains, including health care, financial trading, and accounting. Each of the patterns is described both textually and in a simple pre-UML notation (this book was written before the UML had stabilized into a usable form).

None of the examples in that book show software classes, that is with methods defined in a programming language (that I could find).

I know of at least one book where domain models in fields such as molecular biology have been published in UML. Here's an example (note the UML is modified -- sub-type boxes are shown in super-type boxes -- to save space):

The book above does not model behaviors, probably because they really depend on the requirements of the software application. These models capture some business rules, such as:

• Each Chemical Formulation must be composed of 2 or more of either Chemical Elements or Chemical Compounds, or both.

But the models in that book are mostly data models.

Googling will find you this huge model for the Biomedical Research Integrated Domain Group (BRIDG). Drilling down to the Molecular Biology sub-domain, and to the class Gene, for example, you'll see it has no behavior, nor do any of the other (conceptual) classes in this domain model.

Are domain models in a programming language or not?

Larman's philosophy clearly shows them as programming language-independent (conceptual as opposed to software classes), as a separate artifact from code, to tie them explicitly to the problem domain (requirements).

On the other hand, you'll find Fowler saying, "I prefer POJO domain models.", which is pretty much saying domain models are defined in code.

Eric Evans' DDD makes the assumption that an important degree of complexity in much of software development comes from the domain, and so a model of such complex domains is essential to managing the complexity. Therefore, Domain Modeling is necessary when domains are complex. DDD suggests using a domain modeling language that is ubiquitous; that is, common to the domain experts and the developers. This would imply that in at least some cases, a domain model would not be defined in a programming language.

There is a related question that might shed some light (although it has generated a lot of heat). Some have criticized the question's example as being too trivial (not complex enough) for a justified domain model.