• DDD is a software development approach that uses and builds upon OO design principles.
• The standard definition of the domain is the “sphere of knowledge and activity around which the application logic revolves.”
  • It refers to the subject area on which the application is intended.
• The domain layer, domain logic, or business logic refers to the higher-level rules for how business objects interact with one another to create and modify modeled data.

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.

Common Terms

• Domain: The problem space that should be solved by designing a software.
• 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.
  • This language should resemble the business domain, its terms, entities, and processes.

Bounded Context

• It is a description of a boundary (a subsystem) within which a particular model is defined.
  • An entity in the domain may be classified as a single entity.
    • What if your entity represents multiple definitions in different concepts?
    • You may think about another approach, such as having a different model for a different concept.
      • This is an anti-pattern because a change in one sub-domain can effect the other unrelated models (God object).
  • A bounded context clarifies, encapsulates, and defines the specific responsibility to the model.
    • It ensures the domain will not be distracted from the outside.
    • Each model must have a context implicitly defined within a sub-domain, and every context defines boundaries.

• As you try to model a larger domain, it gets progressively harder to build a single unified model.
  • Different groups of people will use subtly different vocabularies in different parts of a large organization.
• The Total unification of the domain model for a large system will not be feasible or cost-effective.
  • Instead, DDD divides up a large system into Bounded Contexts.
  • Each bounded context can have a unified model, which is essentially a way of structuring Multiple Canonical Models.
• Bounded Contexts have both unrelated concepts (E.g. a support ticket only existing in a customer support context) but also share concepts (E.g. products and customers).
  • Different contexts may have completely different models of common concepts with mechanisms to map between these polysemic concepts for integration.
• Various factors draw boundaries between contexts.
  • Usually, the dominant one is human culture, since models act as Ubiquitous Language, you need a different model when the language changes.
  • You also find multiple contexts within the same domain context, such as the separation between in-memory and relational database models in a single application.