DDD — Notes from the big blue book. Part 7

Chapter 13 — Refactoring Toward Deeper Insight

• Refactoring toward deeper insight may be a response to a problem or awkwardness in the design, where the root of the problem is sensed to be the domain model
• May come even when the code looks tidy — but the language just doesn’t fit the model
• Domain refactorings involve multiple people and are extensively designed and deliberated over
• Could be a refinement of ubiquitious language which is then expressed in the code
• “If you wait until you can make a complete justification for a change — you’ve waited too long. Your project is already incurring heavy costs”
• Refactor when:
• Design does not express current understanding
• Implicit concepts can be made explicit
• Opportunity to make important parts of the domain more supple

Chapter 14 — Maintaining Model Integrity

• Total unification of the domain model will not be feasible or cost-effective
• When inside a context, ignore terminology from outside — focus on keeping that context pure
• Important to understand the bounds of a context
• Duplicate concepts = 2 implementations of the same concept
• False cognates = 2 concepts under the same name
• Create a visual diagram of all the bounded contexts and translations on a project
• Names of bounded contexts should enter the ubiquitous language
• Shared kernel, conformist, open host service, published language
• Anticorruption layers can be used with external systems or legacy code
• Hard for multiple teams to work on one bounded context
• For an existing project, draw up the bounded contexts AS THEY ARE