从专栏出来一篇没有落下的跟到现在，时间真的好快！ 收获良多，算是入了ddd的门，重术(战术)更要重道(战略)，后续打算把ddd分享给身边的人，至少一起码的人要有所了解，有相同的语言，才能一起聊下去 感谢老师，江湖再见！！！

同是保险行业，学完本课程收货很大，之前看了写书理论偏多，本课程中老师分享了很多实践经验，以及具体实施步骤，受益匪浅，感谢。

欧老师的课程内容富有层次，注重整体。 不能一下子都吸收，后序要反复实践、归纳整理，如此循环才能跨过坑和大海。

第一次学习这种几乎纯理论的课程确实很考验耐心，幸运的是老师这种讲课方式很适合我，全部学习了，收获很大，感谢！

老师的专栏组织的很好，既有基础知识的普及，也有原理的分析，还有落地的实战。感谢老师用心的总结与分享，虽然我看到这还有很多云里雾里，这是因为干货太多，自己的脑子不够用而已，计划再看几遍，每篇文章的留言也过一遍

看了很多同道中人提了类似的疑问，分享一下自己的灵魂问题的回答： Q1.一个逻辑，貌似放在应用层、领域服务层、甚至聚合根本身都可以，到底什么是准绳？ A1. （1）首先，分层的本质是为了复用和内聚，切不可成为作茧自缚的存在。 （2）其次，其实每层的定位，老师也说了，应用层是做跨聚合操作的，领域服务层是做聚合内的跨实体操作，而聚合根是自身能触达的对象的。 其实后两者有点含糊，因为聚合根理论上是聚合内四通八达的对象，但领域服务也是。从大家的共识看来，大家都更喜欢纯getter/setter的“容器模型”，而不是一个有“行为”的对象。这点其实老师在案例和回复也默认了，觉得很简单的才放进聚合根（案例里聚合根也就组合了几个setter，搞搞当前时间而已）。 （3）那么，假如觉得放在哪都行，说明他很可能根本就是一个聚合根的“DB基操”，譬如查询、更新请假单这两个操作，压根就是查库、写库。这时候自然是越底层越好（因为越底层将来就越有复用的可能），因此就放在领域服务层了。 Q2：文中一直提到，一旦拆分，引用会失效。 A2： （1）可能是因为我一开始就接触了dubbo之类的rpc框架，我没觉得有什么失效的，毕竟对于dubbo而言，不用考虑是否走网络，将来拆分，大不了为领域对象做个jar包就完事了。 （2）但按照老师说的，的确有一个好处，就是面向抽象，对于调用方来说，不用new大对象了，也不用担心自己set少了东西会导致问题。说白了，就是把关键的信息传过来得了。 Q3:仓储到底解决了什么问题？比起DAO有什么区别？ A3: （1）首先，从老师的案例看来，仓储是依赖了DAO的。而且可以看出，仓储最大的特点，是一个add方法背后偷偷处理了N个表，而不是一个纯纯的小表。 （2）那么更深的灵魂问题来了，从仓储的定位是抽象存储，为何DO转PO这件事会发生在领域服务层（案例里，领域服务调用的factory方法）？按我的理解，至少仓储应该接受、返回DO才对。这点我目前不能理解，还是希望得到老师的回答。 （3）其实大部分互联网公司，尤其java栈都不存在换数据库的担忧，至少SQL大部分时候是标准的、JDBC也是抽象了数据库驱动的。因此，DAO这种读写库的模式已经很够用了。 Q4：DDD到底给我什么意义，解决了目前什么困境？ A4：目前来看，DDD有两个深刻的意义，是我过去没领会到的。 （1）提醒了我，世界上有 领域驱动 vs. 数据驱动 两种套路（不说我都没意识到，这自上而下，自下而上的结果可能大不相同） （2）给了我一个划分“领域、聚合”两种范围，“实体（聚合根）、值对象、事件、命令”这个世界观，以及对应的需求分析方法论。 Q5:值对象的价值在哪？ A5: （1）值对象本是Martin发现基于引用的编程语言在相等比较、写操作的时候互相干扰的问题而特地发明的概念，要求大家不能在值对象做局部写，而只能整个替换。然而实际上大家往往会通过克隆对象避免误写，通过简单的重写equal解决比较，犯不着新增概念。 （2）但我觉的值对象目前有一个更实在好处，就是当两个割裂的模型发生关联的时候，可以作为“快照”或者“实例”的表达。譬如案例中的人员在请假聚合里，表现为“请假人”、“审批者”，这时候只留下人员的名称和id，其他不留。这也意味着，这个人员改名了，在请假单里也是旧的名字（希望这是真实需求吧）。

总结：事件风暴中，我们会根据一些业务操作和行为找出实体(Entity)和值对象(ValueObject)，进而将业务关联紧密的实体和值对象进行组合，构成聚合。再根据业务语义将多个聚合划定到同一个限界上下文(Bounded Context)中，并在限界上下文内完成领域建模。

翻了挺多留言，有一个感觉就是大家的容忍度特别低，总想把DDD的思想或者微服务架构一下子就在项目中完整的落地。就比如，只要使用DDD，在代码层面就不能使用MVC；只要使用微服务架构，就一定要基础设施完善，不然就是垃圾，这可能也是DDD一直推动不下去的原因之一。 人需要不断的学习，团队的认知也需要逐步的完善，是需要时间的。现在的代码是MVC的，没必要推翻，可以先在业务端多与市场、客户成功、产品等角色沟通，尝试用DDD的设计思想来建立合适的模型，等到团队都有这个sense的时候，再去慢慢搞定战术层面的东西。我认为，当业务领域模型足够健壮的时候，即使使用MVC模式，产品的健壮性和可维护性也会高很多。 只有让团队体会到领域设计的好处，才有可能继续推动DDD的落地。 另外一方面，微服务的基础设施也是逐步去构建完善，完全没有必要一开始就大而全。在业务初期，未必要建设庞大的监控系统，通过在代码中打印接口耗时、手动收集业务中的错误日志等方式来监控，也未尝不可，只要适合当前团队就好。 再者，也不用刻意去追求单元测试的覆盖率，能够保证重点业务接口的单元测试覆盖率即可。如果你真的有深入理解TDD的话，你就明白，TDD完全没有要求单元测试覆盖率这种指标，有些接口写单元测试真的只是浪费时间。 最后总结一下，饭是一口一口吃的，路也是一步一步走出来的，多给自己一点耐心，也多给团队一点时间。

欧老师，共享的数据类微服务，也就是数据代码类的数据字典系统应该怎么设计？有什么要点和注意事项吗？某一类字典数据可能只有一张表，是不是有必要把其他类的数据也放到同一个微服务中？比方说品牌库和行业库，各自都只有增删改查的功能。另外，有没有什么好的资料可以提供参考？

平台订单组、支付、营销业务面向用户为核心域，基础资料商品这些为通用域，财务，供应链为支撑域。 不同公司战略不一样，核心域也会不一样