12 | 领域建模：如何用事件风暴构建领域模型？
请订阅文章所属专栏。
精选留言(24)
DwanDDD: 事件风暴--产品愿景--场景分析--领域建模--微服务拆分与设计。
传统: 产品需求--需求分析--详细设计--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- miniluoddd从我做起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