2019-11-11DDD: 事件风暴--产品愿景--场景分析--领域建模--微服务拆分与设计。
传统: 产品需求--需求分析--详细设计--ER模型--UML设计
貌似最后都能产生模型图，一个叫领域模型，一个叫ER图，是不是关键就在这里，一个是面向业务领域建模，一个是面向底层数据层设计，也是DDD和传统的分水岭？作者回复: 是这个意思。DDD领域建模优先，领域建模的时基本不考虑数据模型和数据库实现。在微服务具体落地的时候才考虑数据实体的设计。
1 10
2019-11-14看着这个划分的领域，完全不知道怎么落地。作者回复: 有什么疑问，咱们可以谈讨哈。
3
2019-11-13老师，能给我们说说四色建模或彩色建模？作者回复: 这一块研究的还不太深入呢。后面我再研究一下。
2
2020-01-05个人理解领域建模的核心是识别出领域模型并做到“高内聚，低耦合”；最后一步微服务拆分与设计并不一定是一定要微服务，可以是一个模块、一个包等等。作者回复: 是这样的，其实DDD刚出来的时候并不是为微服务设计的。你可以根据自己得需要，做好领域建模和划分好边界，刚开始并不一定要拆的很细，等真正需要拆分的时候再拆，用DDD设计的系统很容易解耦，很容易拆分出微服务来的。
1
2019-12-23欧老师好，请教个问题：
信贷风控系统，客户提交申请信息，根据客户信息查几十个第三方信息（征信报告、欺诈分、企查查...）来获取客户相关信息然后放到规则引擎跑规则，最后算出客户授信金额。感觉这个系统一时半会没发下手划分领域和子域，麻烦老师指点一下，谢谢！作者回复: 你说的这个场景不是富领域模型，可能找不出聚合根，因此不适合用聚合的方式来做。但是你可以用DDD的分层架构来划分不同的服务，按照外层依赖内层服务的调用关系来开发。
1 1
2019-11-28老师请教一下，领域服务和应用服务的区别是什么？？作者回复: 建议你看一下第7节。DDD分层架构：有效降低层与层之间的依赖。里面有详细介绍。
1
2019-11-12老师，学习到这里还是云里雾里，感觉学了一大堆概念，有个DDD这个理念。公司一般都是需求驱动，很少会花费大量精力去领域建模。老师，请问你们具体是如何推动DDD落地的？作者回复: 领域建模的目的是为了微服务的设计，领域模型是开始，DDD是一种不同于传统设计的方法 ，先有领域模型，然后才有微服务设计，这样设计的微服务边界很清晰，而不是靠拍脑袋设计微服务。等学完后面全部DDD的内容后，你就知道其中的奥秘了。
1- 2019-11-12ddd从我做起 1
2019-11-12感觉最近要做的聚合交易项目就可以小试一下，老师已经列过类和方法名称，对照上下文和聚合可以照着葫芦画瓢了。现行项目不准备也没必要微服务，但是可以写好代码作者回复: 走两次就大概知道怎么去做了。理解了理念以后，就不必受一些条条框框的限制了，路是自己慢慢趟出来的，选择最适合自己的方式。
3 1
2019-11-11可以开始理论结合实践了 ；）👍 1
2020-01-15第一步：从命令和事件中提取产生这些行为的实体。
对于提炼产生行为的实体有点迷惑，难道是「用户创建用户？」「系统创建系统？」
如果说是提炼名词还勉强能说通，请老师指点一下。作者回复: 这里的用户你要区分一下。
第一个是操作系统后产生命令或领域事件的操作用户，这个是外部用例中的用户，可以认为是系统管理员。
第二个是系统中用于记录用户信息和体现用户行为的用户实体，这个用户是领域模型的实体对象。
操作用户通过创建用户这个命令产生了用户这个实体对象，在领域模型中创建用户本身也是用户实体的一个行为。
系统由操作用户创建的。操作用户会创建系统这个实体对象。
2020-01-13有这么一个方法，需要接收很多参数。5个订单领域的参数，1个或2个用户领域的参数，还有时间参数。我们接收一个大而全BO还是接收两三个BO？作者回复: 如果从一个前端来的，你可以做成一个对象，然后在用户接口层完成DTO到DO的转换就可以了。当然DTO和DO之间可以是多对多的转换。
2020-01-04其实传统产品建设流程也会包含前三部（事件风暴、产品愿景、场景分析），这个类似业务需求调研可行性的步骤。只是ddd感觉从宏观更高层次来设计系统，其核心就是找到产品的核心能力以及领域边界，指导确定微服务的服务边界和能力的范围！道与术的差异，技术更多关注的是偏操作和落地，但实际上分析过程就是信息收集、提取、精炼的过程，微服务只是实现方式罢了，信息才是核心（ps又想起吴军的信息与能量了）。作者回复: 是这样的。
2019-12-31我觉得 像这种东西,你理论写的再多,也没什么实践意义,人类天生具备的能力就是模仿,市面上培训DDD的东西那么多,公司那么多,为什么最后还是做不了DDD? 像这种东西,你何不从头就引入 一个业务场景,哪怕不大的,从前到后 拆解出来,比你写这种理论 写一万篇都有用,我说实话,我所有都看完了,除了一些概念,我真的学会领域建模了?
2019-12-28老师，上述领域对象的表格（最后一个表格）中，为什么创建用户属于命令，而分配岗位属于应用服务呢？谢谢作者回复: 这里是分了一下阶段，命令往往会对应服务。领域建模过程通常不知道命令是哪种类型的服务，所以统称命令。微服务设计阶段基本就知道是哪种类型的服务来，所以可以明确出应用服务了。
1
2019-12-27欧老师，好。文中提到：“这些行为可能是一个或若干个命令组合在一起产生的，比如创建用户时，第一个命令是从公司 HR 系统中获取用户信息，第二个命令是根据 HR 的员工信息在用户中台创建用户，创建完用户后就会产生用户已创建的领域事件。”----实践中我们首先可能会想到创建用户的命令，可能就是HR系统发出的“创建用户”命令，文中的案例感觉更像是最终导致创建用户命令的整个过程都罗列出来，像是业务过程。那么实际操作时，怎么理解、怎么把握呢？ 而且单从用户创建的例子来讲，感觉就是一个创建用户的命令就够了。用户数据应该是HR传过来的，如果是这样的流程，是否此处就只要一个hr系统的创建用户命令就够了？作者回复: 不同的公司情况可能会不一样。有的时候在HR创建员工时，并不一定会创建系统用户，因为用户是属于系统的。如果需要给这个员工赋予系统权限，这时候就需要从HR获取员工信息来创建用户，所以创建用户这个过程分成了两个阶段：先获取员工信息，然后再创建用户。
2019-12-24用例分析 -> 事件风暴 （事件改变了哪些对象的状态、属性）-> 领域建模 -> 根据实体关系构建ER图。
ER更能从底层反应出系统的整体架构，领域建模更有利于服务拆分/模块化以及构建出可扩展的系统。
2019-11-26老师，实战篇的领域建模这一课，看完了，还是缺少实际案例和实操步骤。比如，就用户中心来说，首先这个用户中心是准备包括哪些功能的，即把哪些需求放到在这里来实现，然后怎么样对这些需求进行事件风暴，没有一个具体的实操过程，您只是给了几个建好的图示，我还是没能从这个过程中学会如何进行，最终得到这样一个模型。我看后面的课又没讲到这一块了，其实DDD让人摸不着的原因就是缺少手把手的实操案例，所以希望老师能够对领域建模这一环节进行一个完整的案例讲解。谢谢老师！作者回复: 第十八节很详细了呀。
1- 2019-11-22生成菜单 和 岗位有什么关系？不明白
作者回复: 在权限设置的时候，系统会有多个岗位，岗位对应到系统的菜单权限。
2019-11-21欧老师，想问下，相对于事件风暴的，传统需求分析方法是什么？谢谢。作者回复: 传统的需求分析过程大概是这样的：业务人员提出需求-》完成需求分析和设计-》完成系统设计-》开发。。。
需求分析过程中可能也会用到用例分析之类的，但是流程性很明显，主要有需求分析人员完成。 1