Using Domain-Driven software design

In software development, Software design is a mechanism to convert user requirements into a kind of suitable form, which assists the software developer in implementing the actual software code .

Objectives of Software Design¹

1. Correctness: Design should be correct according to the given requirements.
2. Completeness: Design should consist of all components like data structures, modules, external interfaces, etc.
3. Efficiency: Resources should be handled by the program in an efficient and low-cost manner.
4. Flexibility: Ability to modify the code according to changing needs.
5. Consistency: Inconsistencies should not be present in the design.
6. Maintainability: Design should be simple, code to be readable, in order for other developers-designers to be able to maintain the existing code.

In software design, the goal is to divide the problem into manageable pieces.

Benefits of Problem Partitioning¹

1. Software code is easy to understand
2. Software code becomes simple
3. Software code is easier to test
4. Software code becomes easier to change
5. Software code becomes easier to maintain
6. Software code becomes easier to extend

The problem

Organizations require more and more complex business rules to be handled by software application code. Hence, there should be a way to model the business logic, processes plus handle the relations between the entities that make up the business requirements.

As such, we will discuss the Domain Driven Design (DDD) approach

Domain Driven Design was introduced by Eric Evans in 2003 in his book Domain-Driven Design: Tackling Complexity in Heart of Software².

using Eric Evans words,

“When we are developing software our focus should not be primarily on technology, rather it should be primarily on business”

What is a Domain?

Domain logic or Business logic involves the knowledge of the business rules, guidelines and how each domain object should relate and interact with other domain objects.

Lets break down the Design

Domain

It is the heart of the software which contains all the business rules. Here we can find the Entity objects, Aggregates and Value Objects. Interaction and dependencies with third-party libraries should be avoided as much as possible.

Entity is a mutable object, has a unique id and is a representation of a database row. For example, a database table Customer has an Entity class representation called Customer. All Entities are part of the so called Model.

Aggregate is a cluster of domain objects. For example an Order could have multiple Order items.

Value Object is similar to the Entity, but it is immutable and is viewed as a complex Entity attribute which has no unique identifier. For example, Customer Entity has Name and an Address. Address is a complex type, not simple as customer’s name.

Application Layer

Sometimes called, the Service Layer. It defines the boundaries between Application and Presentation Layer It is responsible for orchestrating process flows, by organizing the Domain Layer objects in the below Layer. This layer is ‘thin’, as it does not contain any Business logic. DTO (Data Transfer Objects) are used here as input and output.

Infrastructure Layer

Responsible for communication with external services like databases, message, REST, SOAP services etc… For example Repository classes, which are responsible for data access, are part of this layer.

Presentation Layer

This is the layer where the interaction of the user with the application takes place (pages, UI components). Code here is responsible to handle user requests and in return deliver all the information from the domain to the user’s screen is a sophisticated and structured manner.

Layers of DDD Architecture

As per above screenshot, the collaboration of the Layers is made clear, in that, Application Layer collaborates with lower level Domain Layer, but NOT the other way around. Infrastructure Layer is allowed to collaborate with all layers. Presentation Layer is NOT allowed to call Domain Layer directly.

Advantages of Domain Driven Design

1. Business teams and Developers are fully aligned

2. Business knowledge is maintained in the code, thus no knowledge is lost when old developers move to other projects and new ones come in

3. Provides flexibility with the changing business requirements, due to the fact that the domain logic is fully understood by all members

4. Cleaner and reliable code

Conclusion,

if an organization needs to create software with huge business rul complexity, then DDD architecture is the way to go.

[1] Javatpoint, Software Design Principles https://www.javatpoint.com/software-engineering-software-design-principles

[2] Eric Evans (2003), Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley Professional