限界上下文和四步实现领域建模

2017-04-02 10:15:30

请关注唯心的个人微信公众号:craft6-cn(中划线,也可以搜索:领域驱动业务建模)

限界上下文和领域建模四个步骤


作者 | 颜超敏

网站:craft6.cn。公众号:craft6-cn


1
前言

    关于领域驱动设计的概念和实战,前面已经撰写了几篇文章说明,本文将整个建模过程再进一步介绍限界上下文概念,并把领域建模过程归纳为四个步骤,方便读者记忆和使用。



2
限界上下文定义

限界上下文在《领域驱动设计》一书中并不特别显眼,关于限界上下文的介绍位于第14章的一个小节中。

  Eric Evans 后来回顾说,把 Bounded context 放在14章是一个错误。在最新的 DDD Reference[2] 中,限界上下文已经被提到了第1章第1节,地位凸显。

   IMG_20170311_163810.jpg


限界上下文,限的意思就是划分、规定,界就是界限、或者一个边界,上下文就是业务的整个流程。

    限界上下文定义了领域模型的边界,应该在团队组织、应用中特定部分的使用、代码库和数据库模式等物理表达等方面显式地设定边界。

   限界上下文的目的就是理清子域,然后区分这些子域那些是核心域、支撑子域和通用子域。


一个领域模型涵盖了核心域、子域和限界上下文,其中核心域、子域也可以表达为一个子领域模型,这样一层层嵌套下去。

  • 核心域

   领域模型的主要业务因素,是解决此领域问题主要建模部分。

  • 子域

  对该核心域的提供支撑的关联域 或 系统通用部分的功能支持。

  

   通过子域划分和对领域概念的深入发掘,有助于创建现实世界的更合理抽象。分别思考和实现两个较小规模的系统,要比实现一个大规模的系统容易的多。更细粒度的划分也增加了复用的机会和对业务演进的更好支持。


再看一个图来感受一下限界上下文:

协作系统上下文.png

建模初期把这个领域模型规划出来,可以让团队很清楚这个系统的业务边界在那里,有那些领域模型的元素。



3
限界上下文划分子域的例子

下面是一条简化的网上书店的需求:


“当用户浏览图书时,应该看到图书的书名、作者以及其他用户对本书的评级和文字评论。”


初步建模:

图书馆评论.jpg


设想未来业务变化,网站会销售其它商品,这些商品也需要评论,那么因为图书评论是归属图书领域,所以无法复用。


引入限界上下文概念,划分子域:

图书评论子域.jpg


这样设计后,评论就独立出来了,可以为系统所有允许评论的【资源】进行评论了,比如已购物的订单子项。这样评论子域就可以复用了。



4
领域建模的四个步骤

设计领域模型的步骤.jpg



5
“处理销售”案例的需求

1.  顾客携带购买的商品或服务到达收银台。

2.  收银员开始一次新的销售。

3.  收银员扫码商品或手工输入商品标识。

4.  系统记录卖出去的商品,并显示该商品的描述、价格和累加值。价格可以根据一套定价规则来计算。

收银员重复3~4步,直到结束。

系统显示总金额。

6.  收银员请顾客支付。

7.  顾客选择现金支付或刷卡

7.1 刷卡则到调到银行系统中授权支付。

8.  系统记录完整的销售,并将销售和支付信息发送到外部的记帐系统(进行记帐和提成)和库存系统(更新库存)。

9.  系统打印收据小票。

10.  收银员为顾客将商品装袋。

11. 顾客带者商品和收据小票离开。 



6
步骤一:分析模型(分析需求、候选域)

此购物流程的销售过程是应用层的表现,最终形成销售订单并完成支付是领域层的职责。而支付是销售订单通过外部领域服务完成的订单状态的变更,所以核心在于销售订单。


下面是若干候选域:

  • Sale(销售项)

  • Payment(支付)

  • SalesLineItem(销售项条目)

  • Register(销售点终端)

  • Cashier(收银员)

  • Customer(顾客)

  • Store(商店)

  • Product(商品规格说明)

  • ProductCatalog(商品目录)

  • Stock(商品库存)


根据需求设计活动图:

客服下单流程(craft6-cn).jpg


7
步骤二:识别模型(划分主要构成)

步骤说明:进一步分析领域模型,识别出核心域、子域、实体、值对象、领域服务以及之间的关联;


  • 核心域:销售订单。系统核心需求。

  • 子域:商品、商品目录、商店、支付、库存、收银员、购物车。

  • 实体:销售、销售子项;

  • 值对象:支付方式、支付金额

  • 领域服务:商品服务、顾客服务、支付服务、库存服务

  • 限界上下文:

    • 销售为核心域,本需求围绕这生成销售订单和支付展开。

    • 支付虽然是针对销售订单的支付,但是系统可能存在其它支付业务,所以支付应该独立作为子域。

    • 商品、商品目录、库存等都是对销售的支撑子域,应该保持独立。

    • 商店、收银员等和销售关联程度低,如果有业绩统计,则会关联销售单,方便统计。

    • 购物车:购物车的概念和设计方式视同系统的要求。对于一个单纯的销售系统,购物车相当于暂存架,没有持久化的需要,对于有前端商城,则有持久化的需要,需要构造模型。


8
步骤三:构造模型(聚合和聚合根)
步骤说明:

    根据前面的识别出来的各类对象找出聚合根和聚合边界,初步构造出模型。可以用包图绘制:

销售子域.jpg


以销售模型形成聚合边界,其中聚合根为销售订单,通过和外部的各类业务关联形成各类子域构成。


9
步骤四:细化模型

步骤说明:

基于前面步骤二和三进行模型的细化工作,并反复迭代,确认模型是否满足需求,限界上下文的设计是否合理,是否有利于复用和扩展。


顾客购物聚合边界.jpg        



作 者 简 介


    唯心,颜超敏。 专注Java开源技术和电商、CRM、工作流系统分析、业务建模。

    个人网站:www.craft6.cn

    本文原创,转载请注明出处。







可通过扫描左侧二维码阅读本文。本站文章均为颜超敏原创,欢迎转载,请注明出处即可,转载可通过下面的社会化工具快速完成。

分享到:


为您推荐这些文章,如果感兴趣,请继续阅读吧:

限界上下文和四步实现领域建模

领域驱动设计

阐述领域驱动设计中的限界上下文,并将领域驱动设计归纳为四个简明步骤,方便记忆和使用。

颜超敏,唯心六艺,Craft6.cn,电子商务博客,电子商务研发,电商研发,电子商务研究,电商研究,电子商务专家,电商专家,电子商务知识,电商知识,电子商务教程,电商教程,电子商务模式,电子商务平台,电子商务商业模式,电子商务数据库设计,电商数据库设计,电子商务系统分析,Java架构设计,Java软件架构,B2C,O2O,o2o模式,o2o电子商务,o2o电子商务平台,中国电子商务,电子商务平台建设方案
粤ICP备14060523号 Copyright @2014 -唯心六艺软件