Implementing Domain-Driven Design
Rate it:
Started reading July 20, 2019
7%
Flag icon
The Ubiquitous Language is a shared language developed by the team—a team composed of both domain experts and software developers.
7%
Flag icon
the Language is more centered on how the business itself thinks and operates.
7%
Flag icon
Bounded Contexts are relatively small, smaller than we might at first imagine. A Bounded Context is large enough only to capture the complete Ubiquitous Language of the isolated business domain, and no larger.
7%
Flag icon
If you try to apply a single Ubiquitous Language to an entire enterprise, or worse, universally among many enterprises, you will fail.
8%
Flag icon
Thus, the method in the second example captures the Ubiquitous Language of the model in context, that is, the Bounded Context in which the BacklogItem type is isolated.
9%
Flag icon
A Domain, in the broad sense, is what an organization does and the world it does it in.
9%
Flag icon
Each kind of organization has its own unique realm of know-how and way of doing things. That realm of understanding and its methods for carrying out its operations is its Domain. When you develop software for an organization, you are working in its Domain. It should be pretty obvious to you what your Domain is. You work in it.
10%
Flag icon
A Core Domain is a part of the business Domain that is of primary importance to the success of the organization.
11%
Flag icon
That’s because the Bounded Context is a specific solution, a realization view, once developed. The Bounded Context is used to realize a solution as software.
11%
Flag icon
It is a desirable goal to align Subdomains one-to-one with Bounded Contexts.