Room for More than the Model
A Bounded Context does not necessarily encompass only the domain model. True, the model is the
primary occupant of the conceptual container. However, a Bounded Context is not limited to the
model only. It often marks off a system, an application, or a business service.5 Sometimes a Bounded
Context houses less than this if, for example, a Generic Subdomain can be produced without much
more than a domain model. Consider portions of a system that are typically part of a Bounded
Context.
When the model drives the creation of a persistence database schema, the database schema will
live inside the boundary. This is the case because the schema is designed, developed, and maintained
by the modeling team. It means that the database table names and column names, for example, will
directly reflect names used in the model, rather than names translated to another style. For example,
say our model has a class named BacklogItem and that class has Value Object properties named
backlogItemId and businessPriority:
|
We would expect to see those mapped to the database in like manner:
|
On the other hand, if a database schema is preexisting or if a separate team of data modelers forces
contradicting designs on the database schema, the schema does not live within the Bounded Context
occupied by the domain model.
When there are User Interface (14) views that render the model and drive execution of its
behavior, these are also inside the Bounded Context. However, this does not mean that we model the
Domain in the user interface, causing domain model anemia. We want to reject the Smart UI Anti-
Pattern [Evans] and any temptation to drag domain concepts that belong in the model into other areas
of the system.