Domain Driven Design or DDD for short is a huge but interesting topic. It has many complex subjects focused on business and technical perspectives. In the technology industry, people always talk about how both perspectives should work together in order to give the business benefits. However, that is not an easy task and it is when DDD appears in the scene. In this course, you are going to learn the most important concepts of DDD. You will see some concerns, techniques to model, how DDD can be implemented using hexagonal architecture and many other amazing concepts.

Domain Driven Design (DDD) Made Easy

Modeling a domain can be a difficult task. Once the whole model is done, the next step is to move on to the code. The best approach to translate the domain model into code is to use **Object-Oriented Programming**. Thinking about the interaction between objects is easy. To implement this approach Domain Driven Design defines a number of artifacts that allow technical experts to represent a domain model in the code.

# What is model driven design? 
Model Driven Design says that a software solution should be implemented based on the analysis of models. Remember that a model is an abstraction and representation of something from the real world for the sake of understanding it. Once a domain is modeled, it is possible to begin the implementation of software.

Beyond the Model Driven Design methodology, the Object Management Group (OMG) has created a conceptual framework called **Model Driven Architecture (MDA)**; it provides guidelines for structuring software specifications that are expressed as models. It covers the complete development lifecycle in analysis, design, programming, testing, deployments, and maintenance stages. MDA has three models:
1. **Computation Independent Model (CIM)**: focused on the domain model.
2. **Platform Independent Model (PIM)**: focused on a general platform where a solution will be deployed.
3. **Platform Specific Model (PSM)**: focused on a specific platform where a solution will be deployed.

# What is an entity in the DDD world? 
According to Model Driven Design, DDD has some tactical patterns to represent a model. There are three possible domain objects to implement business logic: Entities, Value Objects, and Aggregates.

In the DDD context, an entity represents something that is involved in a business process. For example, in the context of a bank, some entities may be Account, Credit Card, Customer, or Transaction. An entity has well-defined attributes and domain behavior. Additionally, it is identified by identification such as an ID or a Key, which implies that attribute values may change whenever needed. That is why this domain object is mutable. Attribute values can change without affecting the identification of an object.


Learn what an entity is and how to implement it in the context of Domain Driven Design.

Introduction

Mapping Domain to Model

Domain Activities

Domain Objects

Domain Abstractions

Hexagonal Architecture

Entities