After familiarising myself with Vaughn Vernon’s book Implementing Domain-Driven Design (DDD), I formalised my understanding of the impact the domain model has on making choices for software design. Predominantly with larger systems that could potentially be separated into manifold deployables in the form of service endpoints.

Enterprise Architecture rules and Design by Contract enforcement plays an important role in the governance and policy enforcement of domain model standards and implementation best practices. A domain model offers numerous benefits:

• It helps the team create a common model, between the business and IT stakeholders in the company, that the team can use to communicate about the business requirements, data entities, and process models.
• It improves the reusability and testability of the business domain objects.
• The model is modular, extensible and easy to maintain as the design reflects the business model.

Not spending on a domain model and development effort leads to an application architecture with a "Fat Service Layer" and an "Anemic Domain Model" where business logic and domain objects become mere data carriers with getters and setters. This approach also leads to domain specific business logic and rules being dispersed (and duplicated in some cases) in several different facade classes

Anemic domain models, in most cases, are not cost-effective; they do not give the company a competitive advantage because implementing business requirement changes in this architecture take too long to develop and deploy to the production environment.

Before we look at different architectural and design considerations in a DDD implementation project, let's take a look at the features of a rich domain model.

• The domain model should focus on a specific business operational domain. It should align with the business model, strategies and business processes.
• It should be isolated from other domains in the business as well as other layers in the application architecture.
• It should be reusable to avoid any duplicate models and implementations of the same core business domain elements.
• The model should be loosely coupled with other layers in the application, meaning no dependencies on the layers on either side of the domain layer (i.e. database and facade layers).
• It should be an abstract and cleanly separated layer enabling easier maintenance, testing, and versioning. The domain classes should be unit testable outside the container (and from inside the IDE).
• It should be designed using a POJO programming model (https://en.wikipedia.org/wiki/Plain_Old_Java_Object ) without any technology or framework dependencies (I always tell the project teams I work with that the technology we use for software development is Java).
• The domain model should be independent of persistence implementation details (although the technology does place some constraints on the model).
• It should have minimum dependencies on any infrastructure frameworks because it will outlive these frameworks and we do not want any tight coupling on any external framework.

To achieve a better Return On Investment (ROI) on software development efforts, senior management in Business Units and IT need to commit to the investment (of time, money, and resources) in business domain modeling and its implementation.

Let's look at some of the other factors required for implementing a domain model:

• Analysts should have good business process modeling skills.
• Architects and developers should have strong Object Oriented Design (OOD) and Programming (OOP) experience.
• IT teams (modelers, architects, and developers) should possess good modeling and design skills.
• The team should have regular access to business domain subject matter experts.

Domain modeling and DDD play a vital role in enterprise architecture (EA). Since one of the goals of EA is to align IT with the business units, the domain model that is the representation of business entities, becomes a core part of EA. This is why most of the EA mechanisms (business or infrastructural) should be designed and implemented using the domain model.