Complexity is the driving force for the adoption of the Domain Model pattern. Complexity should be measured in terms of the current requirements and what processes are modeled or automated by the application.
A domain model is a collection of plain old classes, each of which faithfully represents a significant entity in the business domain. These classes are data containers and can expose public properties, but they also are expected to expose methods. The term POCO (Plain Old CLR Object) is often used to refer to classes in a domain model. At some point, the classes in the domain model needs to be persisted. Persistence is not a responsibility of the domain model, and it will happen outside of the domain model through rep
ositories connected to the infrastructure layer.
The conversion between the model and relational store is typically performed by ad hoc tools— specifically, Object/ Relational Mapper (O/ RM) tools, such as Microsoft’s Entity Framework or NHibernate. The unavoidable mismatch between the domain model and the relational model is the critical point of implementing a Domain Model pattern.
For decades (1980 to 1990s), relational data modeling was the most effective way to model the business layer of software applications. In the .NET space, the turning point came in the early 2000s, when more and more companies that still had their core business logic carved in the rough stone of mainframes took advantage of the Microsoft .NET Framework and Internet breakthroughs to renovate and modernize their systems. In only a few years, this poured an incredible amount of complexity on the shoulders of developers. RAD (Rapid Application Development) and relational modeling then— we’d say almost naturally— appeared worn out and their limits were exposed.
All the text above was taken from “Esposito, Dino; Saltarello, Andrea (2014-08-28). Microsoft .NET – Architecting Applications for the Enterprise (2nd Edition) (Developer Reference)” with permission from the authors.
Complexity is tackled best using classes that model the business with ubiquitous language. Language that is understood by the technical modelers (software architects/developers) and by the business counterparts or system matter experts. Domain Services encapsulate services that can be consumed by other applications or different GUIs. The focus now is in modeling the domain and modeling the behavior, rather than modeling the data (RDBM) model without events or behavior. The data model, as a starting point in the design, falls short without modeling the sequence of events (behavior) and the flow of information.