Domain Driven Design – an overview

What is Domain Driven Design?

Domain Driven Design or DDD, is a software development process, which uses Object Oriented Analysis and Design, iteration and expertise within a domain to understand components (objects), functionality and process flows.

The Domain:

In software engineering a domain is the bounded-process area into which the software or an application applies.  In a bounded domain, of say for example Sales, certain logic, flows, inputs, outputs and integration points are present.  The Domain is therefore ‘E Commerce’, and the application logic must consider the functionality of the objects, components and the interaction between objects and components within the bounded (but not isolated), domain, with its associated sub-domains for example; products, inventory, customer module etc.

Domain Layer:

The Domain Layer in software engineering is the Business Logic.  This refers to the higher level rules and logic of how business objects interact with each other (and inside of components), to create and modify modelled data.  The Business Logic layer will be modelled in entity-relationship diagrams, outlining how each object and component interacts and where there are dependencies.

Domain-Driven Design:

Eric Evans introduced the concept in his 2004 book, Domain-Driven Design: Tackling Complexity in the Heart of Software.  Evans states that a domain-driven design will apply and expand upon, the domain concept, in relation to building application software.  The goal is to reduce the complexity of application creation, by connecting the discrete parts of the software application and functionality, into a model which due to its component nature can be changed and modified over time.

There are 3 main aspects of DDD:

1 ) Focus on the core domain and its logic.

2 ) Build the complex designs on the models of the domain (ie business process flow)

3 ) Collaborate on cross-functional teams, with domain experts, in order to model and apply specific domain logic into the technical design.

Common Terms in DDD:

Context: The setting in which a word or statement appears that determines its meaning. Statements about a model can only be understood in a context.

Bounded Context: A description of a boundary (typically a subsystem, or the work of a specific team) within which a particular model is defined and applicable.

Model: A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.

Ubiquitous Language: A language structured around the domain model and used by all team members to connect all the activities of the team with the software.

 

Building Blocks

Domain-driven design also defines a number of high-level concepts that can be used in conjunction with one another to create and modify domain models:

Entity: An object that is identified by its consistent thread of continuity, as opposed to traditional objects, which are defined by their attributes.

Value Object: An immutable (unchangeable) object that has attributes, but no distinct identity.

Domain Event: An object that is used to record a discrete event related to model activity within the system. While all events within the system could be tracked, a domain event is only created for event types which the domain experts care about.

Aggregate: The cluster of entities and value objects with defined boundaries.

Service: Functionality which is needed with the system and domain, but which is outside of an identifiable object, or entity.

Repositories: Service which provides a global entry into objects and entities within an aggregate process. Methods should be defined to allow for creation, modification, and deletion of objects within the aggregate. The repository service will make data queries and remove such queries from within the business logic of the object models.

Factories: This encapsulates the logic of creating complex objects and aggregates, ensuring that the client has no knowledge of the inner-workings of object manipulation.

Sample UML model:

 

Continuous Integration:

DDD helps resolve part of Agile’s weakness which is the lack of a specific design phase.  Iterative domain modelling and subsequent design creation can be viewed as either a strength (my personal view), or a weakness (the view of the Waterfall cult).  DDD does mandate CI/CD including automation of code updates, a single repo (with many branches), blue-green deployment models, automated test cases, unit tests, regression tests and coding error detection.

Advantages of Domain-Driven Design

• Mandates cross-functional teams, including Domain expertise from the beginning of the project
• Based on OOAD and the coding of discrete objects and components (eg. microservices)
• Supports and indeed greatly improves Agile and flexible project structures
• Is not a Waterfall method, but a logical method to build complex systems with integrity and proper design in a manner which is far more accurate, faster and complete that Waterfall based systems
• Business Logic is front and centre of development, not the UI/UX which means that the application will better support, and be more easily modified, the actual business system and its users (as opposed to focusing on UI ease of use and ignore the underlying logical complexity)

Disadvantages of Domain-Driven Design

• Domain expertise is needed and expected. This means non-Technical people must be a part of the project and this is a cultural shift for most firms.  Agile is the best method of cross-functional team building and for most large firms, they are still employing failed Waterfall, and do not understand Agile.
• Iterative practices including ‘scrum meetings’, shared document repos, no ‘islands of power’, and no isolated technical boffins are necessary. Most of these are largely unknown in many VLEs.
• If the project is very technical, but not domain driven, you will not need to use Domain experts, or spend must time on the business logic and process flow. However, this is usually not the case, since most projects rely quite heavily on business logic understanding and component interactions.

 

===END