DEV Community

dima853
dima853

Posted on

Introduction to DDD || Eric Evans

Summary: Domain Models in software development

Image description

1. Models as a simplification of reality

  • An example of an 18th-century Chinese map: — China is depicted in the center, the rest of the countries are schematically shown.
    • This reflected China's isolationist policy, but it did not help to interact with the outside world.
    • Conclusion: A model is ** a simplified representation of reality** that focuses on important aspects and ignores unnecessary ones.

2. What is a Domain?

  • Domain is the user's area of activity that the program concerns.
    • Examples:
  • Airline tickets: real people, planes, flights.
    • Accounting: money, bills, taxes.
    • Version control system: software development.
  • A domain is usually not directly connected to computers, but requires a deep understanding of the subject area.

3. Why do we need domain models?

  • Problem: The amount of domain knowledge is huge and complex.
  • Solution: Model is:
    • Structured simplification of knowledge.
    • Abstraction, which helps to focus on the task.
    • A tool to combat information overload.

4. What is the Domain Model?

  • It's not just a diagram or a code, but the idea that they convey.
  • ** Not "realism"**, but a useful abstraction (like cinema— not real life, but interpretation).
  • Example:
    • The documentary film edits reality to convey meaning.
    • Similarly, the domain model selects the important and discards the unimportant.

5. How is the Domain Model created?

  1. Domain analysis (communication with experts).
  2. Structuring knowledge (highlighting key entities and relationships).
  3. Abstraction (ignoring unnecessary details).
  4. Fixing the model (in the form of diagrams, code or descriptions).

6. Examples of models

Real world Model in the program
Passenger, Plane, flight Class Passenger, Flight
Money, accounts, transactions Account, Transaction

7. Conclusion

  • Domain Model is a deliberately simplified representation of knowledge about a domain.
  • She helps:
    • Understand complex processes.
    • Communicate between developers and experts.
    • Create software that solves users' real-world problems.

Key point: A good model is not one that is "realistic", but one that is useful for solving a specific problem.

Summary: The role of the model in Domain-Driven Design (DDD)

1. Three key model functions in DDD

  1. The model forms the design of the system, and the design clarifies the model

  2. The model is closely related to the implementation, which makes it relevant.

    • The code can be interpreted through the lens of the model (convenient with support and development).
    • Example: If the model includes the entity Order, then the code will have the class Order with the appropriate methods.

  3. The model is the basis of a single team language (Ubiquitous Language)

  4. Domain developers and experts speak the same language.

    • There is no need to "translate" the requirements.
    • The language helps to refine the model itself.
    • Example: The term "order cancellation" in the speech of experts → the method Order.cancel()in the code.

  5. A model is a condensed knowledge of a domain

    • The team has agreed on how to structure knowledge about the subject area.
    • The model captures important concepts and their interrelationships.
    • Experience working with early versions of the software helps to improve the model.

2. Why is the model the "heart" of the software?

  • The main task of PO is ** to solve the problems of the subject area**.
  • Complex domains require deep understanding:
  • Developers must immerse themselves in business logic.
    • Technical skills (frameworks, algorithms) are secondary without understanding the domain.
  • Risk: Developers often focus on technology, ignoring domain → create complex but useless systems.

3. Example: A story from Monty Python

  • On the set of Monty Python and the Holy Grail, one shot didn't turn out to be funny.
  • The actors changed the scene — it became funny, but the editor used the old version because the sleeve was visible in the new one.
  • Analogy in development:
    • Editor = a developer who takes care of the technical details but loses the point.
    • Director = team leader who returns the focus to the domain (as a funny scene).

4. Advantages of deep domain work

  • Complexity is interesting: — Creating a clear model in a chaotic domain is an intellectual challenge.
  • Modeling skills make a developer more valuable:
    • The ability to identify entities, aggregates, and constraints is useful in any project.
  • System approaches:
  • Tactical DDD (Entity, Value Object, Aggregate).
    • Strategic DDD (Bounded Context, Context Map).

5. Conclusion

  • A good model is not just documentation, but a decision—making tool.
  • DDD helps:
  • Connect code with business logic.
    • Avoid "technical narcissism" (when technology is more important than the task).
    • Create software that really solves user problems.

Key quote:
"The heart of software is its ability to solve problems in a subject area. Everything else is auxiliary."

Additional concepts to explore:

  • Tactical DDD: Entity vs Value Object, Aggregates, Repositories.
  • Strategic DDD: Bounded Context, Anti-Corruption Layer.
  • Practices: Event Storming, Domain Storytelling.

Top comments (1)

Collapse
 
voncartergriffen profile image
Von Carter Griffen •

Love the comparison to documentaries and cinematic edits—turning messy reality into Oscar-worthy code! Great intro to making software less “Monty Python editor” and more problem-solver.