Types of Domain Models

Previously, I stated my preference for putting domain above technology and infrastructure concerns when implementing software systems. However, we can express domain in multiple ways, and not all of them have the same quality characteristics.

Kinds

Therefore, in this section, I want to provide more guidelines on possibilities.

Rich domain

A rich domain model is a preferred form of implementing domain layers of software systems. There are many good explanations“Domain Driven Design” - a book by Eric Evans of the rich domain in literature or on the internet (see Tengiz Modeling, Tengiz HTDBO, and Tengiz IOM). For that reason, I will not explain it once again in this section.

The rich domain model helps achieve maximum benefits out of delivered software systems because this approach tackles complexity in code and therefore brings down maintenance and enhancement costs in the long run.

Anemic domain

An anemic domain model is considered an anti-pattern in the software architecture area of knowledge. It sits on the opposite pole from the rich domain that I mentioned above. You need to know what it is to avoid it at all costs, so please make sure that you learn about it in available literature“Domain Driven Design” - a book by Eric Evans or on the internet.

The anemic domain model is one of the primary enemies of long-running software projects. It promotes mixing technology with a domain or spreading knowledge thin throughout the entire codebase of application. Therefore, programs implemented in this manner will not help software developers to quickly gain domain knowledge and feel comfortable with making changes to the existing implementation. As a result of this shortcoming, affected software projects will show signs of a slowdown and low quality, which decreases ROI and customer satisfaction.

Big ball of mud

The term “Big Ball Of Mud” (see here) describes software solutions that are hard to understand, maintain, enhance, or run. These programs give diminishing returns on investment. Therefore, I recommend avoiding this style of development and architecture at all times.