Domain Driven Design - amitbhilagude/userfullinks GitHub Wiki

  1. Domain-Driven Design(DDD)

    1. It is used to solve problems of the complex business domains and it is not used for solving technical complexity.
    2. DDD should be used only for complex business problems, It is not used if you have a simple domain or simple CRUD operation service.
    3. It is a good option for customers, businesses to convenience the problem or speak in their terminology.
    4. the First step of this design is to collaborate with a Domain expert and get the Domain related queries and requirements. Make sure you don't talk much any programming language with domain expert to confuse him.
    5. Write the high level of flow or view of the requirements.
    6. Concepts-
      1. Core Domain: Main customer Domain
      2. SubDomians: Seperate domain
      3. BoundedContext: Boundries between context
      4. ContextMapping: Flow in domain
      5. Entity(Domain class in DDD but it is data model in EF core). Context(Boundexcontext in DDD but it is DBContext in EF core). It is good practice to create EntityBase class e.g. Id will be the mandatory for each entity then we can move this under Entity base class
      6. ValueObject: ValueObjects are also classed but they are immutable. These classes don't have persistence in DB. E.g. You have a class that will do some calculation and get the result back. It is ValueObject. They are short-span objects. Create more value OBjects than entities as they light weights and you can use Entity to perform Wrapper on top of ValueObject. Create most of the domain logic inside ValueObjecs.
    7. Software projects have the below area. DDD is used for solving complex business logic. Good for enterprise applications
      1. Complex business logic
      2. Performance is key
      3. Technical complexity
      4. Amount data

  2. Bounded Context

    1. This is second after getting requirements from a Domain expert.
    2. BoundedContext is to define the boundary of the context so that they will not overlap. E.g. If you are building a system for Appointment scheduling and payment after the visit. It will be two different Bounded contexts like Appointment Scheduling and Billing and we don't want to use patient details common between them as Patient CC details or billing details are not necessary during Appointment Scheduling. So this context can have client details managed separately and not to share the same client view so these are bounded contexts with no overlap.
    3. When we start the coding by considering bounded context, keep these separate either by creating namespace, folder or projects.

  3. Context Map

    1. Context map is used to define boundary.
    2. Shared kernel: There could be scenario that some common area needs to be shared between multiple bounded context then it can be put as Shared Kerned
    3. Microservice architecture for each boundary.

  4. Ubiquitious Language

    1. Common Language between with Domain expert and architect to avoid any requirement misunderstanding

  5. Valueobject

    1. Value Object is immutable. This is one of the concepts in DDD to find a class that needs to be implemented as Immutable.
    2. In general, We don't want to replace any single property of this class, we should be expected to update all properties. I.e. create new objects always.

  6. Aggregates and Aggreateroot

    1. Aggregates are used to create relationships between Entities. It is recommended to use the one-directional relationship to avoid complexity.
    2. Each aggregate can have aggregateroot.
    3. Common entities always used together for final outcome or DB updated can be consolidated into Aggreates.
    4. We can have one aggregate per repository pattern

  7. Repository Pattern

    1. needs to identify which object needs to be persistent storage in DB or Non-persistenet storage
    2. Repository pattern will have abstract layer and it can be interacted with Interfaces
    3. Need to have clear details do we need to have in-memory collection or caching etc.

  8. Domain Events

    1. Good for notifying events between bounded context

  9. Anti-corruption Layer

    1. There could be scenarios that you already have DDD and there is another legacy application and don't want to break your DDD.
    2. Create Anti-corruption layer using Adapter pattern.

  10. Should we use DDD in Microservices Architecture

    1. Microservice needs to be isolated without being dependent on others however DDD will have bounded context may have shared kernel and Entities.
    2. It is recommended to use DDD within a single Microservice and each Microservice can have BoundedContext.

  11. Github samples

    1. https://github.com/mehdihadeli/ecommerce-microservices