Excerpted from DomainDrivenDesignBook

Problem: Even though team members may know broadly what constitutes the CoreDomain, different people won't pick out quite the same elements, and even the same person won't be consistent from one day to the next. The mental labor of constantly filtering the model to identify the key parts absorbs concentration better spent on design thinking, and it requires comprehensive knowledge of the model. The CoreDomain must be made easier to see.

Significant structural changes to the code are the ideal way of identifying the CoreDomain, but they are not always practical in the short term. In fact, such major code changes are difficult to undertake without the very view the team is lacking.

Solution:
Write a very brief DistillationDocument (three to seven sparse pages) that describes the CoreDomain and the primary interactions among CORE elements.

Flag the elements of the CoreDomain within the primary repository of the model, without particularly trying to elucidate its role. Make it effortless for a developer to know what is in or out of the CORE.

If the DistillationDocument outlines the essentials of the CoreDomain, then it serves as a practical indicator of the significance of a model change. When a model or code change affects the distillation document, it requires consultation with other team members. When the change is made, it requires immediate notification of all team members, and the dissemination of a new version of the document. Changes outside the CORE or to details not included in the distillation document can be integrated without consultation or notification and will be encountered by other members in the course of their work. Then the developers have the full autonomy that XP suggests.

HighlightedCore is mentioned on: MessagesByTopic