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:



public class BacklogItem extends Entity {
...
private BacklogItemId backlogItemId;
private BusinessPriority businessPriority;
...
}

We would expect to see those mapped to the database in like manner:



CREATE TABLE `tbl_backlog_item` (
...
`backlog_item_id_id` varchar(36) NOT NULL,
`business_priority_ratings_benefit` int NOT NULL,
`business_priority_ratings_cost` int NOT NULL,
`business_priority_ratings_penalty` int NOT NULL,
`business_priority_ratings_risk` int NOT NULL,
...
) ENGINE=InnoDB

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.

将有界上下文比喻成模型住的房子,其实不应该将有界上下文和模型
之间建立关系,而是考虑有界上下文和聚合之间的关系。

还谈到了模型和数据表结构的关系,模型驱动方式应该是先有模型,然后有数据表结构,而不是相反。

我们谈上下文的关系,主要是讲业务需求中的有界上下文,除了这个,还有其他上下文。

上下文和聚合之间的关系是显隐关系,也就是阴阳关系,上下文是阴,聚合是显示的阳,如同国家和首都之间的关系,国家边界是有界上下文,首都是其中的聚合根。我说北京,其实隐式指中国的北京。

从需求中首先划分上下文边界,聚合根也就出来,当然,也可以先找出聚合根,再找出其背后的上下文,比如我们看地图,首先找北京 上海这些城市实体,然后再看看它们的边界在哪里。这些都是朴素的分析方式。

建议参考 建模风暴这个PPT,我比较赞同他的观点。http://www.slideshare.net/ziobrando/model-storming-a-different-approach-to-collaborative-model-discovery-vilnius-edition