背景
看了这篇文章：Coding for Domain-Driven Design: Tips for Data-Focused Devs，对 BoundedContext 的设计有了一点新的体会，记录下来，加强记忆。
Sometimes All You Need Is CRUD
Not everything in your app needs to be created using DDD. DDD is there to help handle complex behaviors. If you just need to do some raw, random editing or querying, then a simple class (or set of classes), defined just as you’d typically do with EF Code First (using properties and relationships) and combined with insert, update and delete methods (via a repository or just DbContext), is all you need. So, to accomplish something like creating an order and its line items, you might want DDD to help work through special business rules and behaviors. For example, is this a Gold Star customer placing the order? In that case, you need to get some customer details to determine if the answer is yes, and, if so, apply a 10 percent discount to each item being added to the order. Has the user provided their credit-card information? Then you might need to call out to a verification service to ensure it’s a valid card.
The key in DDD is to include the domain logic as methods within the domain’s entity classes, taking advantage of OOP instead of implementing “transactional scripts” within stateless business objects, which is what a typical demo-ware Code First class looks like.
But sometimes all you’re doing is something very standard, like creating a contact record: name, address, referred by, and so forth, and saving it. That’s just create, read, update and delete (CRUD). You don’t need to create aggregates and roots and behaviors to satisfy that.
Most likely your application will contain a combination of complex behaviors and simple CRUD. Take the time to clarify the behaviors and don’t waste time, energy and money over-architecting the pieces of your app that are really just simple. In these cases, it’s important to identify boundaries between different subsystems or bounded contexts. One bounded context could be very much data-driven (just CRUD), while a critical core-domain-bounded context should, on the other hand, be designed following DDD approaches.
上文主要表达的思想是：我们可以将系统分解为多种 bounded context，那些以数据为中心的 boundex context 可以按照数据驱动进行开发，那些比较复杂和核心领域可以采用领域驱动开发。
用四色原型来思考
四色原型中的 MI 是系统建模的中心，MI 也反应了系统的流程，因此将 MI 的开发非常适合领域驱动。而 PPT 和 Des 多数是以数据为中心的，因此针对 PPT 和 Des 的开发非常适合数据库驱动。
备注
Boundex Context 划分可以应对复杂性，但是不同 Boundex Context 之间如何共享数据和行为是一个需要认真对待的事情，这里可能会增加复杂性。