Vaughn specializes in consulting around Domain-Driven Design and DDD using the Actor model with Scala and Akka. (link)
He is the author of the best-selling books Implementing Domain-Driven Design and Reactive Messaging Patterns with the Actor Model, also published by Addison-Wesley. (link)
Using Domain Events will help you both to model explicitly and to share what has occurred within your model with the systems that need to know about it. The (link)
Tactical design is like using a thin brush to paint the fine details of your domain model. One of the more important tools is used to aggregate entities and value objects together into a right-sized cluster. It’s the Aggregate pattern. (link)
You will also see how to integrate multiple Bounded Contexts using a technique called Context Mapping. (link)
First you will learn how to segregate your domain models using the strategic design pattern called Bounded Contexts. Hand in glove, you will see how to develop a Ubiquitous Language as your domain model within an explicitly Bounded Context. (link)
Strategic design is used like broad brushstrokes prior to getting into the details of implementation. (link)
Most people make the mistake of thinking design is what it looks like. People think it’s this veneer—that the designers are handed this box and told, “Make it look good!” That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works.
—Steve Jobs (link)
In Scrum, knowledge acquisition is done through experimentation and collaborative learning and is referred to as “buying information” [Essential Scrum]. (link)
One model employed minimal, base intellect. The other model exploited maximum cognition. Software can be modeled from either perspective (link)
These makeshift thoroughfares aren’t traveled today because they were well designed, but because they exist (link)
—Book Design: A Practical Introduction by Douglas Martin (link)
Questions about whether design is necessary or affordable are quite beside the point: design is inevitable. The alternative to good design is bad design, not no design at all. (link)
This all seems to happen in the spirit of “no design yields lower-cost software.” (link)
Developers are too wrapped up with technology and trying to solve problems using technology rather than careful thought and design. (link)
The policy in each of these business areas exists for different reasons. There is no escaping this fact, and no amount of mental gymnastics changes this. (link)
Thus, a Big Ball of Mud is often the result of unbridled effort made by a team of software developers who don’t listen to the business experts. (link)
To understand one big reason to use Bounded Contexts, let’s consider a common problem with software designs. Often teams don’t know when to stop piling more and more concepts into their domain models (link)
It is especially important to be clear that one team works on a single Bounded Context (link)
This is the primary value proposition of DDD, and you want to invest appropriately by committing your best resources to a Core Domain. (link)
A Core Domain is developed to distinguish your organization competitively from all others (link)
In short, DDD is primarily about modeling a Ubiquitous Language in an explicitly Bounded Context (link)
. In the end the code is the model and the model is the code (link)
Both developers and Domain Experts should reject any tendency to allow documents to rule over conversation (link)
Still, you are using DDD because the business model is more complex than the technical aspects of the project. That’s why the developers have to dig into the business model with Domain Experts! (link)
This generally means that if the events are published as JSON, or perhaps a more economical object format, the consumer should consume the events by parsing them to obtain their data attributes. (link)
Going Asynchronous with REST
It’s possible to accomplish asynchronous messaging using REST-based polling of a sequentially growing set of resources (link)
Using messaging is one of the most robust forms of integration because you remove much of the temporal coupling associated with blocking forms such as RPC and REST. (link)
The book REST in Practice [RiP] is a good place to start. (link)
An Open Host Service defines a protocol or interface that gives access to your Bounded Context as a set of services. T (link)
An Anticorruption Layer is the most defensive Context Mapping relationship, where the downstream team creates a translation layer between its Ubiquitous Language (model) and the Ubiquitous Language (model) that is upstream to it. The layer isolates the downstream model from the upstream model and translates between the two. Thus, this is also an approach to integration. (link)
A team will often become a Conformist, for example, when integrating with a very large and complex model that is well established. Example: Consider the need to conform to the Amazon.com model when integrating as one of Amazon’s affiliate sellers. (link)
A Customer-Supplier describes a relationship between two Bounded Contexts and respective teams, where the Supplier is upstream (the U in the diagram) and the Customer is downstream (the D in the diagram). (link)
A Shared Kernel, depicted on page 54 by the intersection of the two Bounded Contexts, describes the relationship between two (or more) teams that share a small but common model. (link)
Considering that in two different Bounded Contexts there are two Ubiquitous Languages, this line represents the translation that exists between the two languages. (link)
Each team is responsible for one Bounded Context. They create a Partnership to align the two teams with a dependent set of goals (link)
When we talk about Context Mapping, what is of interest to us is what kind of inter-team relationship and integration is represented by the line between any two Bounded Contexts. (link)
You also learned that the Agile Project Management Core Domain would have to integrate with other Bounded Contexts. That integration is known in DDD as Context Mapping (link)
Even so, it is only the business that can determine the acceptable time frame for updates to occur between various Entities. Some are immediate, or transactional, which means they must be managed by the same Aggregate. Some are eventual, which means they may be managed through Domain Events and messaging, for example (link)
Some are immediate, or transactional, which means they must be managed by the same Aggregate. Some are eventual, which means they may be managed through Domain Events and messaging, for example. (link)
This exercise indicates that eventual consistency is business driven, not technically driven. (link)
Don’t get taken in by this alluring, highly abstract implementation trap. Model the Ubiquitous Language explicitly according to the mental model of the Domain Experts that is refined by your team (link)
When using functional programming, the rules change considerably. While an Anemic Domain Model is a bad idea when using object-oriented programming, it is somewhat the norm when applying functional programming. (link)
Place your business logic in your domain model, or suffer bugs sponsored by an Anemic Domain Model. (link)
One big, nasty hook is the Anemic Domain Model [IDDD]. This is where you are using an object-oriented domain model, and all of your Aggregates have only public accessors (getters and setters) but no real business behavior. (link)
Each Aggregate forms a transactional consistency boundary. (link)
The name of the Root Entity is the Aggregate’s conceptual name. (link)
Each Aggregate is composed of one or more Entities, where one Entity is called the Aggregate Root. Aggregates may also have Value Objects composed on them. (link)
The main thing that separates an Entity from other modeling tools is its uniqueness—its individuality. (link)
The interested Bounded Context can be the same one from which the Domain Event was published, or it could be different Bounded Contexts. (link)
As part of the BacklogItem Aggregate’s transaction, it publishes a Domain Event named BacklogItemCommitted. The BacklogItem transaction completes and its state is persisted along with the Backlog-ItemCommitted Domain Event. (link)
Another benefit to using reference by identity only is that your Aggregates can be easily stored in just about any kind of persistence mechanism, such as relational database, document database, key-value store, and data grids/fabrics. (link)
Perhaps most importantly, these Aggregates will have transactional success much more frequently than the previous large-cluster Product Aggregate. (link)
Rule 1 means that the business should ultimately determine Aggregate compositions based on what must be consistent when a transaction is committed. (link)
Let’s next consider the four basic rules of Aggregate design:
-
Protect business invariants inside Aggregate boundaries.
-
Design small Aggregates.
-
Reference other Aggregates by identity only.
-
Update other Aggregates using eventual consistency. (link)
A Domain Event is a record of some business-significant occurrence in a Bounded Context. (link)