DDD实战课
欧创新
人保高级架构师
立即订阅
4865 人已学习
课程目录
已完结 23 讲
0/2登录后,你可以任选2讲全文学习。
开篇词 (1讲)
开篇词 | 学好了DDD,你能做什么?
免费
基础篇 (5讲)
01 | 领域驱动设计:微服务设计为什么要选择DDD?
02 | 领域、子域、核心域、通用域和支撑域:傻傻分不清?
03 | 限界上下文:定义领域边界的利器
04 | 实体和值对象:从领域模型的基础单元看系统设计
05 | 聚合和聚合根:怎样设计聚合?
进阶篇 (6讲)
06 | 领域事件:解耦微服务的关键
07 | DDD分层架构:有效降低层与层之间的依赖
08 | 微服务架构模型:几种常见模型的对比和分析
09 | 中台:数字转型后到底应该共享什么?
10 | DDD、中台和微服务:它们是如何协作的?
答疑:有关3个典型问题的讲解
实战篇 (10讲)
11 | DDD实践:如何用DDD重构中台业务模型?
12 | 领域建模:如何用事件风暴构建领域模型?
13 | 代码模型(上):如何使用DDD设计微服务代码模型?
14 | 代码模型(下):如何保证领域模型与代码模型的一致性?
15 | 边界:微服务的各种边界在架构演进中的作用?
16 | 视图:如何实现服务和数据在微服务各层的协作?
17 | 从后端到前端:微服务后,前端如何设计?
18 | 知识点串讲:基于DDD的微服务设计实例
19 | 总结(一):微服务设计和拆分要坚持哪些原则?
20 | 总结(二):分布式架构关键设计10问
结束语 (1讲)
结束语 | 所谓高手,就是跨过坑和大海!
DDD实战课
登录|注册

12 | 领域建模:如何用事件风暴构建领域模型?

欧创新 2019-11-11
你好,我是欧创新。
还记得我在 [第 01 讲] 中说过,微服务设计为什么要选择 DDD 吗?其中有一个非常重要的原因,就是采用 DDD 方法建立的领域模型,可以清晰地划分微服务的逻辑边界和物理边界。可以说,在 DDD 的实践中,好的领域模型直接关乎微服务的设计水平。因此,我认为 DDD 的战略设计是比战术设计更为重要的,也正是这个原因,我们的内容会更侧重于战略设计。
那么我们该采用什么样的方法,才能从错综复杂的业务领域中分析并构建领域模型呢?
它就是我在前面多次提到的事件风暴。事件风暴是一项团队活动,领域专家与项目团队通过头脑风暴的形式,罗列出领域中所有的领域事件,整合之后形成最终的领域事件集合,然后对每一个事件,标注出导致该事件的命令,再为每一个事件标注出命令发起方的角色。命令可以是用户发起,也可以是第三方系统调用或者定时器触发等,最后对事件进行分类,整理出实体、聚合、聚合根以及限界上下文。而事件风暴正是 DDD 战略设计中经常使用的一种方法,它可以快速分析和分解复杂的业务领域,完成领域建模
那到底怎么做事件风暴呢?事件风暴需要提前准备些什么?又如何用事件风暴来构建领域模型呢?今天我们就来重点解决这些问题,深入了解事件风暴的全过程。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《DDD实战课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(24)

  • Dwan
    DDD: 事件风暴--产品愿景--场景分析--领域建模--微服务拆分与设计。
    传统: 产品需求--需求分析--详细设计--ER模型--UML设计
    貌似最后都能产生模型图,一个叫领域模型,一个叫ER图,是不是关键就在这里,一个是面向业务领域建模,一个是面向底层数据层设计,也是DDD和传统的分水岭?

    作者回复: 是这个意思。DDD领域建模优先,领域建模的时基本不考虑数据模型和数据库实现。在微服务具体落地的时候才考虑数据实体的设计。

    2019-11-11
    1
    5
  • marker
    老师,能给我们说说四色建模或彩色建模?

    作者回复: 这一块研究的还不太深入呢。后面我再研究一下。

    2019-11-13
    2
  • 张迪
    看着这个划分的领域,完全不知道怎么落地。

    作者回复: 有什么疑问,咱们可以谈讨哈。

    2019-11-14
    1
  • 守候、
    老师,学习到这里还是云里雾里,感觉学了一大堆概念,有个DDD这个理念。公司一般都是需求驱动,很少会花费大量精力去领域建模。老师,请问你们具体是如何推动DDD落地的?

    作者回复: 领域建模的目的是为了微服务的设计,领域模型是开始,DDD是一种不同于传统设计的方法 ,先有领域模型,然后才有微服务设计,这样设计的微服务边界很清晰,而不是靠拍脑袋设计微服务。等学完后面全部DDD的内容后,你就知道其中的奥秘了。

    2019-11-12
    1
  • miniluo
    ddd从我做起
    2019-11-12
    1
  • 北天魔狼
    感觉最近要做的聚合交易项目就可以小试一下,老师已经列过类和方法名称,对照上下文和聚合可以照着葫芦画瓢了。现行项目不准备也没必要微服务,但是可以写好代码

    作者回复: 走两次就大概知道怎么去做了。理解了理念以后,就不必受一些条条框框的限制了,路是自己慢慢趟出来的,选择最适合自己的方式。

    2019-11-12
    3
    1
  • LS
    可以开始理论结合实践了 ;)👍
    2019-11-11
    1
  • 西野
    老师请教一下,领域服务和应用服务的区别是什么??

    作者回复: 建议你看一下第7节。DDD分层架构:有效降低层与层之间的依赖。里面有详细介绍。

    2019-11-28
  • @倾杯
    老师,实战篇的领域建模这一课,看完了,还是缺少实际案例和实操步骤。比如,就用户中心来说,首先这个用户中心是准备包括哪些功能的,即把哪些需求放到在这里来实现,然后怎么样对这些需求进行事件风暴,没有一个具体的实操过程,您只是给了几个建好的图示,我还是没能从这个过程中学会如何进行,最终得到这样一个模型。我看后面的课又没讲到这一块了,其实DDD让人摸不着的原因就是缺少手把手的实操案例,所以希望老师能够对领域建模这一环节进行一个完整的案例讲解。谢谢老师!

    作者回复: 第十八节很详细了呀。

    2019-11-26
    1
  • 张迪
    生成菜单 和 岗位有什么关系?不明白

    作者回复: 在权限设置的时候,系统会有多个岗位,岗位对应到系统的菜单权限。

    2019-11-22
  • 观弈道人
    欧老师,想问下,相对于事件风暴的,传统需求分析方法是什么?谢谢。

    作者回复: 传统的需求分析过程大概是这样的:业务人员提出需求-》完成需求分析和设计-》完成系统设计-》开发。。。
    需求分析过程中可能也会用到用例分析之类的,但是流程性很明显,主要有需求分析人员完成。

    2019-11-21
    1
  • TH
    还有一个问题:如果不使用事件驱动架构,那么发布-订阅模式会被简单的函数调用模式所取代,这时候关注重点是否变成了命令而不是事件?由命令转化为各个实体功能或者领域/应用服务。

    作者回复: 是的。

    2019-11-18
  • TH
    之前也一直疑惑于领域建模和技术架构异构的问题,看来结合实际情况,领域模型和微服务也不一定是一对一的关系。有位同学留言说他们按DDD建模但是最终以单体部署,这也是我目前的情况,因为还没有搭建起微服务运行的条件(我们用的是Python,没有很好的框架可以用,而且我们做的是桌面应用)。但是我觉得这不妨碍DDD的落地,至少按DDD的思路对项目进行合理分层、把需求落实到各个领域对象,这对后续的需求变更和架构演进都有好处。

    作者回复: 这样理解就对了。
    理解核心理念后,灵活运用。

    2019-11-18
  • 川杰
    您好,有个地方没明白:
    虽然应用层和领域层都可以进行事件的发布和处理,但为了实现事件的统一管理,我建议你将微服务内所有事件的发布和订阅的处理统一放到应用层,事件相关的核心业务逻辑放在领域层。通过应用层调用领域层服务,来实现完整的事件发布和订阅处理流程。
    假设场景:
    事件:密码已重置;
    订阅着:消息通知服务;
    业务流程:密码重置事件发生;消息通知服务响应,发送邮件至客户邮箱;

    通过应用层来调用领域服务,来实现完整的事件发布和订阅处理流程。
    如果以以上场景为例,请问这句话什么意思?是不是说:
    在应用层完成,通知事件的订阅;然后,应用层调用 通知服务(领域)的API,完成业务流程?

    作者回复: 订阅在应用层,事件的处理属于领域逻辑所以放在领域层。应用服务通过调领域层逻辑来实现。

    2019-11-14
  • 张迪
    用户信息领域为什么有分配岗位?

    作者回复: 在权限域吧。

    2019-11-14
  • liuchangit
    老师,请教个问题:用户中台分为用户信息、权限、认证三个限界上下文,对应开发三个微服务。用户中心一般需要有管理后台供运营人员管理操作,也会给业务系统提供接入的api接口等,那么这三个微服务都各自包含自身的管理后台和api接口吗?一般情况下,管理后台访问很低,占用资源少,也不需要高可用,一般放在内网;API接口访问量大,需要部署多实例,一般会暴露在公网;管理后台和API放在一个微服务内,从资源隔离、可用性和安全性都不合理,如果放在两个微服务,那数据库有几个?

    作者回复: 领域模型只是根据业务属性来建立的初步的模型,它的建立过程主要是偏业务多一些,微服务的拆分还需要具体场景具体分析,需要考虑系统的高性能、安全性、版本发布频率是否一致、团队沟通成本等等。每个企业的情况都不一样,不能一概而论。
    你的这个分析很好,拆分的时候就是要考虑这些内容。

    2019-11-14
    1
  • Alan思宇
    老师,请教个问题:
    比如在订单业务,主要有订单、退款单、换货单、支付单、物流单,这里支付单和物流单并不是实际的支付流水和快递运单,只是订单里面需要维护的支付数据及物流信息数据。
    我们现在划分出了三个领域,分别是订单域、逆向域、换货域;
    不过不管是订单、逆向还是换货,其实都需要支付单和物流单,那么这块应该怎么设计呢?再划分出单独的支付单域和物流单域,作为支撑域 去服务上面三个业务域么?

    作者回复: 支付单和物流单的数据是来源于支付和物流域吧。订单域、逆向域和换货域这三个域里的聚合根只是引用支付和物流域的数据吧,订单和支付和物流的数据都是一对一不?如果是一对一,并且需要整体替换,而且不会针对在订单上对支付和物流数据做大量查询统计,你可以将支付和物流的数据设计为订单聚合根的值对象,如果这几不满足,你将它们设计为订单聚合根的引用实体也行。不需要在订单业务中,再设计支付单域和物流单域。

    2019-11-13
  • 你的美
    欧老师好,我们做新项目微服务开发,先把DDD架构整体设计好,然后在根据模块做封装,最后在部署到单体结构里运行,这样的流程可以吗?谢谢老师辛苦

    作者回复: 不理解你为什么做了微服务还要放在单体里面运行呢?
    是因为没有容器这些云平台吗?还是为了整体运维和与原来的单体集成方便?
    其实你可以将它部署为单独的微服务,然后暴露接口给原来的单体应用,中间做一个接口的协议转换就可以了,如果两者业务逻辑上有差异,需要适配的话,你也可以加一层防腐层代码,避免污染领域模型。

    2019-11-13
    1
  • 锦鲤
    老师,你好,大家理解的DDD都是自底向上进行业务领域建模设计,从企业整体角度来看,可能这个方法只是从微观层面上解决了部分问题,不能从整体宏观层面上解决跨领域级的问题。之前有分享过DDD也可以自上而下的进行领域建模设计。那么这种方式是否解决跨领域级的业务问题?它和企业级业务架构的方法有什么不同吗?

    作者回复: 其实两者都是建立企业级的业务架构的策略,自顶向下主要从业务角度出发,而自底向上呢主要从业务和系统现状出发,考虑现有系统情况会更多一些。虽然领域建模时都是在一个小的业务域内,但是最后都还有一个模型查重的过程,以解决模型跨域重复的问题。

    2019-11-13
  • 美美
    老师,请教一下。
    比如门店设置页可以设置功能A开启,功能B关闭,功能C暂停,这种配置类的后台如何进行领域建模,实体怎么分析出来。。

    作者回复: 在分析的时候,会分析出修改配置项的命令的,这个命令会对配置项实体操作,可能对应到一个应用服务。而这个实体初始化的数据可能来源于数据库配置,或者配置中心,或者文件。

    2019-11-12
收起评论
24
返回
顶部