Definition

Domain Driven Design is the concept that the structure and language of software code (class names, class methods, class variables) should match the business domain. For example, if a software processes Health care Records, it might have classes such as Patient and Doctor, and methods such as Admit and Submit Diagnosis respectively.
In this post I will try to answer the following questions about DDD:

• What is the Domain?
• What is the Domain Driven Design?
• What are the Building Blocks for Domain Driven Design?
• What are the Advantages of Domain-Driven Design?
• What are the disadvantages of Domain-Driven Design?

What is the Domain?

To get the idea behind the domain driven design we need to establish an understanding for what is the Domain.
A Domain the what most of the developers call business logic that describes the business rules, validations and behaviors that can be performed.

What is the Domain Driven Design?

The Domain Driven Design is initially introduced back in 2004 by Eric Evans in his book, Domain-Driven Design: Tackling Complexity.
In a nutshell Domain Driven Design is the expansion of the Domain concept when reflecting it to the software development. It aims to ease the creation of complex applications by connecting the related pieces of the software into an ever-evolving model. DDD focuses on three core principles:

• Focus on the core domain and domain logic.
• Base complex designs on models of the domain.
• Constantly collaborate with domain experts, to improve the application model and resolve any emerging domain-related issues.

Evans defined the common terms when describing the Domain Driven Design practices:

• 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.
• 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.
• 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.

What are the Building Blocks for Domain Driven Design?

Below are the high-level concepts that can be used when implementing Domain Driven design, using these concepts will result in a rich and usable development domain.

• Entity: An object that is identified by its consistent thread of continuity, as opposed to traditional objects, which are defined by their attributes.
• Example, a Diagnosis is an entity that have its attributes also it will be persisted to a separate repository unit Diagnosis Table if we are using a database.
• Value Object: An immutable (unchangeable) object that has attributes, but no distinct identity.
• Example, Address is a value object that contains attributes and does not have an Id that represent it, it will be as a sub attribute to an entity and incase the Address is changed a new object will be created. 
• 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.
• Example: When adding a new patient to the system we need other parts of the application to identify that a new patient is added and handle the logic for it, like opening a financial account for this patient in the financial system.
• Aggregate: A collection of objects that are bound together by a root entity, otherwise known as an aggregate root. The aggregate root guarantees the consistency of changes being made within the aggregate by forbidding external objects from holding references to its members.
• Service: Essentially, a service is an operation or form of business logic that doesn’t naturally fit within the realm of objects. In other words, if some functionality must exist, but it cannot be related to an entity or value object, it’s probably a service.
• Repositories: the DDD meaning of a repository is a service that uses a global interface to provide access to all entities and value objects that are within a particular aggregate collection. Methods should be defined to allow for creation, modification, and deletion of objects within the aggregate. However, by using this repository service to make data queries, the goal is to remove such data query capabilities from within the business logic of object models.
• Factories: As we’ve discussed through a number of design patterns articles already, DDD suggests the use of a factory, which encapsulates the logic of creating complex objects and aggregates, ensuring that the client has no knowledge of the inner-workings of object manipulation.

What are the Advantages of Domain-Driven Design?

• Eases Communication: With an early emphasis on establishing a common and ubiquitous language related to the domain model of the project, teams will often find communication throughout the entire development life cycle to be much easier. Typically, DDD will require less technical jargon when discussing aspects of the application, since the ubiquitous language established early on will likely define simpler terms to refer to those more technical aspects.
• Improves Flexibility: Since DDD is so heavily based around the concepts of object-oriented analysis and design, nearly everything within the domain model will be based on an object and will, therefore, be quite modular and encapsulated. This allows for various components, or even the entire system, to be altered and improved on a regular, continuous basis.
• Emphasizes Domain Over Interface: Since DDD is the practice of building around the concepts of domain and what the domain experts within the project advise, DDD will often produce applications that are accurately suited for and representative of the domain at hand, as opposed to those applications which emphasize the UI/UX first and foremost. While an obvious balance is required, the focus on domain means that a DDD approach can produce a product that resonates well with the audience associated with that domain.

What are the disadvantages of Domain-Driven Design?

To help maintain the model as a pure and helpful language construct, the team must typically implement a great deal of isolation and encapsulation within the domain model. Consequently, a system based on domain-driven design can come at a relatively high cost. While domain-driven design provides many technical benefits, such as maintainability, Microsoft recommends that it be applied only to complex domains where the model and the linguistic processes provide clear benefits in the communication of complex information, and in the formulation of a common understanding of the domain.

What’s Next?

In this post I hope that I have explained the theory behind the Domain Driven Design, please keep following us for the next post which I will talk about a step by step example.