Knowledge Extraction in Domain-Driven Design || DDD Eric Evans

Summary: Knowledge Extraction in Domain-Driven Design (Chapter 1) 1. Problem: Ignorance of the subject area The author, a software developer, was faced with the task of creating a program for designing printed circuit boards (PCBs), having no knowledge of electronics. Attempt 1: Get TK from experts → fail. Experts have proposed primitive solutions (for example, sorting ASCII files) that do not solve real problems. Problem: The gap between technical and substantive knowledge. 2. The process of "Knowledge Crunching" Method: Collaborative modeling through: Dialogue with experts: The author drew diagrams (informal UML), the experts corrected them. Example: Expert: "These are not chips, but component instances." Developer: Clarified the terms (for example, "ref-des" = reference designator = component instance). Focusing on a single function: Disassembled "probe simulation" — analysis of signal delays in the circuit. Simplified the model: ignored the physics of the chips, focused on the topology of the connections. Iterative refinement of the model: Developer's questions: "How is the signal transmitted beyond the Pin?" → Found out: through * "pushes"* components. "What counts as a 'hop'?" → Network transition (Net) = 1 hop. Result: A model of objects (Net, Pin, Component) with behavior. 3. Creating a prototype Goal: To test the model in practice. Prototype Features: No UI, no persistence, just logic. Tests + output to the console. Effect: Experts saw the work of the model → the dialogue became more specific. The code and the model evolved together. 4. The final model Key entities: Net (connection). Pin (component contact). Component (the type of component that defines the "jolts" of the signal). Excluded: Physical parameters of the components (did not affect the task). Advantages of the model: Eliminated synonyms (for example, "ref-des" = "component instance"). Gave a single language for the team. Allowed new developers to quickly understand the logic. 5. Lessons A model is born in a dialogue — you can't just take TK from experts. Focus on specific scenarios — for example, "probe simulation". A prototype without "excess" helps to test ideas quickly. The evolution of the model and the code — they must change together. Quote: "A model is a concise knowledge that excludes irrelevant details, but preserves the essence of the problem." Additional concepts Ubiquitous Language is a common language for developers and experts. Tactical DDD — Entity (Component), Value Object (Pin), Aggregates. Iteration — The model is religion, it can be changed as you learn. Conclusion: The success of the project depends on deep immersion in the domain, and not only on technology. Ingredients of Effective Modeling Certain things we did led to the success I just described. Binding the model and the implementation That crude prototype forged the essential link early, and it was maintained through all subsequent iterations. Cultivating a language based on the model At first, the engineers had to explain elementary PCB issues to me, and I had to explain what a class diagram meant. But as the project proceeded, any of us could take terms straight out of the model, organize them into sentences consistent with the structure of the model, and be un-ambiguously understood without translation. Developing a knowledge-rich model The objects had behavior and enforced rules. The model wasn't just a data schema; it was integral to solving a complex problem. It captured knowledge of various kinds. Distilling the model Important concepts were added to the model as it became more complete, but equally important, concepts were dropped when they didn't prove useful or central. When an unneeded concept was tied to one that was needed, a new model was found that distinguished the essential concept so that the other could be dropped. Brainstorming and experimenting The language, combined with sketches and a brainstorming attitude, turned our discussions into laboratories of the model, in which hundreds of experimental variations could be exercised, tried, and judged. As the team went through scenarios, the spoken expressions themselves provided a quick viability test of a proposed model, as the ear could quickly detect either the clarity and ease or the awkwardness of expression. It is the creativity of brainstorming and massive experimentation, leveraged through a model-based language and disciplined by the feedback loop through implementation, that makes it possible to find a knowledge-rich model and distill it. This kind of knowledge crunching turns the knowledge of the team into valuable models.

May 26, 2025 - 11:40

Knowledge Extraction in Domain-Driven Design || DDD Eric Evans

Summary: Knowledge Extraction in Domain-Driven Design (Chapter 1)

1. Problem: Ignorance of the subject area

The author, a software developer, was faced with the task of creating a program for designing printed circuit boards (PCBs), having no knowledge of electronics.

Attempt 1: Get TK from experts → fail.
- Experts have proposed primitive solutions (for example, sorting ASCII files) that do not solve real problems.
Problem: The gap between technical and substantive knowledge.

2. The process of "Knowledge Crunching"

Method: Collaborative modeling through:

Dialogue with experts:
The author drew diagrams (informal UML), the experts corrected them.
- Example:
Expert: "These are not chips, but component instances."
- Developer: Clarified the terms (for example, "ref-des" = reference designator = component instance).
Focusing on a single function:
Disassembled "probe simulation" — analysis of signal delays in the circuit.
- Simplified the model: ignored the physics of the chips, focused on the topology of the connections.
Iterative refinement of the model:
- Developer's questions:
"How is the signal transmitted beyond the Pin?" → Found out: through * "pushes"* components.
- "What counts as a 'hop'?" → Network transition (Net) = 1 hop.
  - Result: A model of objects (Net, Pin, Component) with behavior.

3. Creating a prototype

Goal: To test the model in practice.
Prototype Features:
No UI, no persistence, just logic.
- Tests + output to the console.
Effect:
Experts saw the work of the model → the dialogue became more specific.
- The code and the model evolved together.

4. The final model

Key entities:
Net (connection).
- Pin (component contact).
- Component (the type of component that defines the "jolts" of the signal).
Excluded:
Physical parameters of the components (did not affect the task).
Advantages of the model:
Eliminated synonyms (for example, "ref-des" = "component instance").
- Gave a single language for the team.
- Allowed new developers to quickly understand the logic.

5. Lessons

A model is born in a dialogue — you can't just take TK from experts.
Focus on specific scenarios — for example, "probe simulation".
A prototype without "excess" helps to test ideas quickly.
The evolution of the model and the code — they must change together.

Quote:
"A model is a concise knowledge that excludes irrelevant details, but preserves the essence of the problem."

Additional concepts

Ubiquitous Language is a common language for developers and experts.
Tactical DDD — Entity (Component), Value Object (Pin), Aggregates.
Iteration — The model is religion, it can be changed as you learn.

Conclusion: The success of the project depends on ** deep immersion in the domain**, and not only on technology.

Ingredients of Effective Modeling

Certain things we did led to the success I just described.

Binding the model and the implementation
That crude prototype forged the essential link
early, and it was maintained through all subsequent iterations.
Cultivating a language based on the model
At first, the engineers had to explain
elementary PCB issues to me, and I had to explain what a class diagram meant. But as the
project proceeded, any of us could take terms straight out of the model, organize them into
sentences consistent with the structure of the model, and be un-ambiguously understood
without translation.
Developing a knowledge-rich model
The objects had behavior and enforced rules. The
model wasn't just a data schema; it was integral to solving a complex problem. It captured
knowledge of various kinds.
Distilling the model
Important concepts were added to the model as it became more
complete, but equally important, concepts were dropped when they didn't prove useful or
central. When an unneeded concept was tied to one that was needed, a new model was
found that distinguished the essential concept so that the other could be dropped.
Brainstorming and experimenting
The language, combined with sketches and a
brainstorming attitude, turned our discussions into laboratories of the model, in which
hundreds of experimental variations could be exercised, tried, and judged. As the team went
through scenarios, the spoken expressions themselves provided a quick viability test of a
proposed model, as the ear could quickly detect either the clarity and ease or the
awkwardness of expression.

It is the creativity of brainstorming and massive experimentation, leveraged through a model-based
language and disciplined by the feedback loop through implementation, that makes it possible to
find a knowledge-rich model and distill it. This kind of knowledge crunching turns the knowledge
of the team into valuable models.