| 编辑推荐: |
关于领域驱动设计的概念和实战，前面已经撰写了几篇文章说明，本文将整个建模过程再进一步介绍限界上下文概念，并把领域建模过程归纳为四个步骤，方便读者记忆和使用。
希望你能在本文找到答案！
本文来自craft6.cn，由火龙果软件yf编辑、推荐。
|
|
1 限界上下文定义
限界上下文在《领域驱动设计》一书中并不特别显眼，关于限界上下文的介绍位于第14章的一个小节中。
Eric Evans 后来回顾说，把 Bounded context
放在14章是一个错误。在最新的 DDD Reference[2] 中，限界上下文已经被提到了第1章第1节，地位凸显。
限界上下文，限的意思就是划分、规定，界就是界限、或者一个边界，上下文就是业务的整个流程。
限界上下文定义了领域模型的边界，应该在团队组织、应用中特定部分的使用、代码库和数据库模式等物理表达等方面显式地设定边界。
限界上下文的目的就是理清子域，然后区分这些子域那些是核心域、支撑子域和通用子域。
一个领域模型涵盖了核心域、子域和限界上下文，其中核心域、子域也可以表达为一个子领域模型，这样一层层嵌套下去。
核心域
领域模型的主要业务因素，是解决此领域问题主要建模部分。
子域
对该核心域的提供支撑的关联域 或 系统通用部分的功能支持。
通过子域划分和对领域概念的深入发掘，有助于创建现实世界的更合理抽象。分别思考和实现两个较小规模的系统，要比实现一个大规模的系统容易的多。更细粒度的划分也增加了复用的机会和对业务演进的更好支持。
再看一个图来感受一下限界上下文：
建模初期把这个领域模型规划出来，可以让团队很清楚这个系统的业务边界在那里，有那些领域模型的元素。
2 限界上下文划分子域的例子
下面是一条简化的网上书店的需求：
“当用户浏览图书时，应该看到图书的书名、作者以及其他用户对本书的评级和文字评论。”
初步建模：
设想未来业务变化，网站会销售其它商品，这些商品也需要评论，那么因为图书评论是归属图书领域，所以无法复用。
引入限界上下文概念，划分子域：
这样设计后，评论就独立出来了，可以为系统所有允许评论的【资源】进行评论了，比如已购物的订单子项。这样评论子域就可以复用了。
3 领域建模的四个步骤
4“处理销售”案例的需求
1． 顾客携带购买的商品或服务到达收银台。
2． 收银员开始一次新的销售。
3． 收银员扫码商品或手工输入商品标识。
4． 系统记录卖出去的商品，并显示该商品的描述、价格和累加值。价格可以根据一套定价规则来计算。
收银员重复3~4步，直到结束。
系统显示总金额。
6． 收银员请顾客支付。
7． 顾客选择现金支付或刷卡
7.1 刷卡则到调到银行系统中授权支付。
8． 系统记录完整的销售，并将销售和支付信息发送到外部的记帐系统（进行记帐和提成）和库存系统（更新库存）。
9． 系统打印收据小票。
10. 收银员为顾客将商品装袋。
11. 顾客带者商品和收据小票离开。
5 步骤一：分析模型（分析需求、候选域）
此购物流程的销售过程是应用层的表现，最终形成销售订单并完成支付是领域层的职责。而支付是销售订单通过外部领域服务完成的订单状态的变更，所以核心在于销售订单。
下面是若干候选域
1.Sale(销售项)
2.Payment(支付)
3.SalesLineItem(销售项条目)
4.Register(销售点终端)
5.Cashier(收银员)
6.Customer(顾客)
7.Store(商店)
8.Product(商品规格说明)
9.ProductCatalog(商品目录)
10.Stock（商品库存）
根据需求设计活动图：
6 步骤二：识别模型（划分主要构成）
步骤说明：进一步分析领域模型，识别出核心域、子域、实体、值对象、领域服务以及之间的关联；
核心域：销售订单。系统核心需求。
子域：商品、商品目录、商店、支付、库存、收银员、购物车。
实体：销售、销售子项；
值对象：支付方式、支付金额
领域服务：商品服务、顾客服务、支付服务、库存服务
限界上下文：
销售为核心域，本需求围绕这生成销售订单和支付展开。
支付虽然是针对销售订单的支付，但是系统可能存在其它支付业务，所以支付应该独立作为子域。
商品、商品目录、库存等都是对销售的支撑子域，应该保持独立。
商店、收银员等和销售关联程度低，如果有业绩统计，则会关联销售单，方便统计。
购物车：购物车的概念和设计方式视同系统的要求。对于一个单纯的销售系统，购物车相当于暂存架，没有持久化的需要，对于有前端商城，则有持久化的需要，需要构造模型。
7 步骤三：构造模型（聚合和聚合根）
步骤说明：
根据前面的识别出来的各类对象找出聚合根和聚合边界，初步构造出模型。可以用包图绘制：
以销售模型形成聚合边界，其中聚合根为销售订单，通过和外部的各类业务关联形成各类子域构成。
8 步骤四：细化模型
步骤说明：
基于前面步骤二和三进行模型的细化工作，并反复迭代，确认模型是否满足需求，限界上下文的设计是否合理，是否有利于复用和扩展。
|
