您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
限界上下文和领域建模四个步骤
 
作者 | 颜超敏
  4167  次浏览      15
 2021-7-13 
 
编辑推荐:
关于领域驱动设计的概念和实战,前面已经撰写了几篇文章说明,本文将整个建模过程再进一步介绍限界上下文概念,并把领域建模过程归纳为四个步骤,方便读者记忆和使用。 希望你能在本文找到答案!
本文来自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 步骤四:细化模型

步骤说明:

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

   
4167 次浏览       15
相关文章

为什么要做持续部署?
剖析“持续交付”:五个核心实践
集成与构建指南
持续集成工具的选择-装载
 
相关文档

持续集成介绍
使用Hudson持续集成
持续集成之-依赖管理
IPD集成产品开发管理
相关课程

配置管理、日构建与持续集成
软件架构设计方法、案例与实践
单元测试、重构及持续集成
基于Android的单元、性能测试
最新课程计划
信息架构建模(基于UML+EA)3-21[北京]
软件架构设计师 3-21[北京]
图数据库与知识图谱 3-25[北京]
业务架构设计 4-11[北京]
SysML和EA系统设计与建模 4-22[北京]
DoDAF规范、模型与实例 5-23[北京]
 
最新文章
iPerson的过程观:要 过程 or 结果
“以人为本”的工程哲学
企业架构、TOGAF与ArchiMate概览
UML 图解:顺序图( sequence diagram )
UML 图解:对象图( class diagram )
最新课程
基于UML和EA进行系统分析设计
UML+EA+面向对象分析设计
基于SysML和EA进行系统设计与建模
UML + 嵌入式系统分析设计
领域驱动的建模与设计
更多...   
成功案例
某电信运营供应商 应用UML进行面向对象分析
烽火通信 UML进行面向对象的分析设计
西门子 UML与嵌入式软件分析设计
航天科工某子公司 从系统到软件的分析、设计
深圳某汽车企业 模型驱动的分析设计
更多...