码迷,mamicode.com
首页 > 其他好文 > 详细

学习:DDD领域驱动设计

时间:2019-02-28 10:35:11      阅读:234      评论:0      收藏:0      [点我收藏+]

标签:分析   one   抽象   nts   业务流程   ddd   包含   参与   存储   

DDD:Domain-driven Design(领域 - 驱动 -> 设计)

->领域驱动领域模型设计

->领域模型驱动代码实现

 

摘自网络(汤雪华的博客

《概念总结》

    1. 领域就是问题域,有边界,领域中有很多问题;
    2. 任何一个系统要解决的那个大问题都对应一个领域;
    3. 通过建立领域模型来解决领域中的核心问题,模型驱动的思想;
    4. 领域建模的目标针对我们在领域中所关心的问题,即只针对核心关注点,而不是整个领域中的所有问题;
    5. 领域模型在设计时应考虑一定的抽象性、通用性,以及复用价值;
    6. 通过领域模型驱动代码的实现,确保代码让领域模型落地,代码最终能解决问题;
    7. 领域模型是系统的核心,是领域内的业务的直接沉淀,具有非常大的业务价值;
    8. 技术架构设计或数据存储等是在领域模型的外围,帮助领域模型进行落地;

《拆分领域》

  领域建模的基础是要先理解领域,让自己成为领域专家。如果做到了这点,我们就打好了坚实的基础了。

但是,有时一个领域往往太复杂,涉及到的领域概念、业务规则、交互流程太多,导致我们没办法直接针对这个大的领域进行领域建模。

所以,我们需要将领域进行拆分,本质上就是把大问题拆分为小问题,然后各个击破的思路。

然后既然把一个大的领域划分为了多个小的领域(子域),那最关键的就是要理清每个子域的边界;然后要搞清楚哪些子域是核心子域,哪些是非核心子域,哪些是公共支撑子域;然后,还要思考子域之间的联系是什么。

那么,我们该如何划分子域呢?我的个人看法是从业务相关性的角度去思考,也就是我们平时说的按业务功能为出发点进行划分。

《细化子域》

    1. 梳理领域概念:梳理出领域内我们关注的概念、概念的关系,并统一交流词汇,形成统一语言;
    2. 梳理业务规则:梳理出领域内我们关注的各种业务规则,DDD中叫不变性(invariants),比如唯一性规则,余额不能小于零等;
    3. 梳理业务场景:梳理出领域内的核心业务场景,比如电商平台中的加入购物车、提交订单、发起付款等核心业务场景;
    4. 梳理业务流程:梳理出领域内的关键业务流程,比如订单处理流程,退款流程等;

  *关于领域概念的梳理,我觉得可以采用四色原型分析法

《领域模型设计》

  DDD原著中提出了很多实用的建模工具:聚合、实体、值对象、工厂、仓储、领域服务、领域事件。

    1. 划分好边界上下文,通常每个子域(sub domain)对应一个边界上下文(bounded context),同一个边界上下文中的概念是明确的,没有任何歧义;
    2. 在每个边界上下文中设计领域模型,具体的领域模型设计方法有很多种,如以场景为出发点的四色原型分析法,或者我早期写的这篇文章;这个步骤最核心的就是找出聚合根,并找出每个聚合根包含的信息;
    3. 关于如何设计聚合,可以看一下我写的这篇文章
    4. 画出领域模型图,圈出每个模型中的聚合边界;
    5. 设计领域模型时,要考虑该领域模型是否满足业务规则,同时还要综合考虑技术实现等问题,比如并发问题;领域模型不是概念模型,概念模型不关注技术实现,领域模型关心;所以领域模型才能直接指导编码实现;
    6. 思考领域模型是如何在业务场景中发挥作用的,以及是如何参与到业务流程的每个环节的;
    7. 场景走查,确认领域模型是否能满足领域中的业务场景和业务流程;
    8. 模型持续重构、完善、精炼;

《领域模型的核心作用》

    1. 抽象了领域内的核心概念,并建立概念之间的关系;
    2. 领域模型承担了领域内的状态的维护;
    3. 领域模型维护了领域内的数据之间的业务规则,数据一致性;

学习:DDD领域驱动设计

标签:分析   one   抽象   nts   业务流程   ddd   包含   参与   存储   

原文地址:https://www.cnblogs.com/xdyin/p/10448549.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!