01 | 领域驱动设计：微服务设计为什么要选择DDD？
该思维导图由 AI 生成，仅供参考
软件架构模式的演进
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
领域驱动设计（DDD）在微服务设计中的重要性备受关注。微服务架构时代，团队往往面临微服务边界的划定困境，缺乏系统的理论和方法来指导微服务的拆分。领域驱动设计（DDD）填补了这一空白，通过定义领域模型来确定业务和应用边界，保证业务模型与代码模型的一致性。越来越多的人开始将DDD作为微服务设计的指导思想，利用DDD设计方法来建立领域模型，划分领域边界，并根据这些边界来划分微服务边界，实现微服务内部和外部的“高内聚、低耦合”。领域驱动设计在微服务设计中扮演着重要角色，已成为大型互联网企业微服务的主流设计方法。DDD的战略设计可以帮助建立领域模型，划定领域边界，解决微服务设计过程中的边界难题。DDD不仅适用于微服务，也适用于传统的单体应用。
《DDD 实战课》，新⼈⾸单¥59
全部留言(138)
- 最新
- 精选
Geek_a91670置顶事件风暴到底是什么啊?作者回复: 后面章节会有一章专门讲，会有一个案例。跟头脑风暴类似，通过它设计领域模型。
2019-10-21713
吴建中
面对复杂问题，解决办法通常是拆分，模块化，化整为零。领域驱动建模DDD是面向业务，对业务领域的划分和整合，是逻辑层面。微服务是面向物理落地，是对应用的物理形态进行拆分和整合。从软件工程过程角度看，DDD的战略设计输出物，领域模型及划分的区域，是微服务的输入，一个区域对应一个微服务，微服务运行框架、平台可以承载所有的微服务，提供微服务统一的运行框架，也就是承载所有的业务领域。可见领域驱动与微服务是在软件不同阶段使用的工具，技术或方法论，围绕一个共同的目标，搭建企业业务中台，企业级业务复用，快速的需求响应能力。DDD战略设计得输出，是微服务的输入。作者回复: 👍高手，每节的总结可以交给你来做了😀。
2019-12-1413196
SkyeDance翻了挺多留言，有一个感觉就是大家的容忍度特别低，总想把DDD的思想或者微服务架构一下子就在项目中完整的落地。就比如，只要使用DDD，在代码层面就不能使用MVC；只要使用微服务架构，就一定要基础设施完善，不然就是垃圾，这可能也是DDD一直推动不下去的原因之一。 人需要不断的学习，团队的认知也需要逐步的完善，是需要时间的。现在的代码是MVC的，没必要推翻，可以先在业务端多与市场、客户成功、产品等角色沟通，尝试用DDD的设计思想来建立合适的模型，等到团队都有这个sense的时候，再去慢慢搞定战术层面的东西。我认为，当业务领域模型足够健壮的时候，即使使用MVC模式，产品的健壮性和可维护性也会高很多。 只有让团队体会到领域设计的好处，才有可能继续推动DDD的落地。 另外一方面，微服务的基础设施也是逐步去构建完善，完全没有必要一开始就大而全。在业务初期，未必要建设庞大的监控系统，通过在代码中打印接口耗时、手动收集业务中的错误日志等方式来监控，也未尝不可，只要适合当前团队就好。 再者，也不用刻意去追求单元测试的覆盖率，能够保证重点业务接口的单元测试覆盖率即可。如果你真的有深入理解TDD的话，你就明白，TDD完全没有要求单元测试覆盖率这种指标，有些接口写单元测试真的只是浪费时间。 最后总结一下，饭是一口一口吃的，路也是一步一步走出来的，多给自己一点耐心，也多给团队一点时间。作者回复: 彩！
2021-01-209127
Geek_9695b4我们公司现在也有这方面的想法，但是一直无从下手，主要原因是， 1、我们是给工厂做软件的，不同的工厂相同的功能需求会有有差异，这个怎么解决？显然一个工厂一个版本是不好的 2、不同工厂需要使用不同的数据库 3、功能模块主要有物料管理、订单管理、计划管理、出入库管理、库存管理等，里面功能模块较多 4、DDD怎么更好的去解决SAAS化的产品研发问题作者回复: 第一个问题，我想知道不同工厂软件需求的差异主要在什么地方？如果差异在流程和服务编排，DDD的分层架构应用服务很合适。如果领域层业务逻辑差异不大的话，就比较好解决。个人感觉领域层的核心逻辑差异应该不会大。 第二个问题，DDD数据库方面采用依赖倒置的方式，实现业务逻辑的时候，不会有数据库方面的逻辑，都是领域对象的行为，数据库相关代码在仓储实现中实现。也就是说业务实现与数据库是松耦合的，换数据库的时候，只需要换仓储逻辑就可以了，不会影响核心业务逻辑。 第三方问题，你说的这几个子域相对清晰，直接在子域做事件风暴，建立领域模型，设计微服务就可以了。 第四个问题，见以上三条。总之，保持领域层领域模型的稳定，用应用层去适配外部需求的变化，用户接口层面向不同渠道提供个性数据服务。
2019-10-25750
女干部我能说我等极客时间出这个等了1年吗？编辑回复: 忠实老粉了啊～期待你的打卡！
2019-10-14834
雷霹雳的爸爸当然是微服务架构，不是也得跟投资人宣称是 要说最大的问题，就是业务拎不清；让我更进一步分析这种状况，应该是就没有事实上的领域专家，只有很多充其量是熟悉现有业务流程的人，而这些人站在自己的视角阐述问题都没有问题，但是缺少能捏合起来统筹考虑的人，在我们的组织中（我怀疑大多数组织中都是这样），在产品研发团队，关于业务的话语权特别是信息垄断权是掌握在产品（经理）部门手中的，而微服务、DDD的武器却是掌握在技术部门手中，如果技术人员不赶紧学好吃透这些招式，这就对微服务的实际落地，DDD的推广应用，带来了巨大的障碍和困难，我觉得也别无他法，只能忍着被误解和做好顶雷背锅的心态，像Carty说的那样，技术团队中有人挺身而出去承担本该产品经理的责任吧，这样才能给DDD，微服务落地准备足够的营养...我还记得在这个团队在成立初期，产品总监戏称应该定一个组织结构设计架构师的岗位，我估计他主要是说给我这个技术架构师听的，而我只能一脸严肃地表达，确实组织架构应该根据你系统演化的需要来变更的，我就差说你回去好好看看书去不行吗？作者回复: 其实你说的这种现象很普遍，很多企业都是业务的归业务，技术的归技术。不容易融合，这也是很多技术难以推行的原因。
2019-10-30428
忠厚中台是战略目标，DDD是设计思想，微服务是落地手段，云原生是落地基础....企业数字化转型四大核心知识体系，一个都不能少，哈哈哈哈...作者回复: 是的，它们是整个中台体系的方法和技术框架。还缺少一个前端的设计：微前端。我在后面会讲到。
2020-03-22319
huaweichen我之前的公司从legacy单体应用转型为DDD微服务， 最大的问题是： 1. 使用消息队列的过程中，有很多事件不同步、死循环问题。 2. legacy数据库和新数据库的同步。 3. 做reporting的时候，不知道有什么好的招术。作者回复: 第一个问题，不清楚是设计的问题还是消息中间件组件选择的问题。 第二个问题，数据库之间的同步可以采用两种方式，第一种定时扫描源端数据库获取增量数据，但是这种方式会增加数据库的负担和需要单独编写取数代码逻辑。第二种是采用数据库日志捕获技术CDC，但是不知道你这种数据库是否有CDC，如果没有，就不太方便了。 第三个问题，不知道你的报表数据来源，如果是多个微服务，那建议你做一个数据平台，用于汇集各个微服务数据库的数据，所有的报表从这个数据平台获取。
2019-11-04318
姚俊从2016年偶然间发现了springcloud springboot，于是开始带领团队玩起了微服务，在有一些技术积累之后，开始反过来看做过的项目，发现微服务的拆分并没有带来多少好好处，于是今年开始ddd试错。在拆分过程中，个人碰到的几大问题就是 1、数据库彻底拆分之后，带来的编码问题，和多服务调用的性能问题，举个例子，性别代码表，在n多个系统都需要的情况下，如果复制，也数据库没有彻底拆分，或者有冗余，彻底拆分的话，原来关联查询简单的sql，则变成服务之间的调用，可能存在性能问题。比较棘手 2、接触ddd有几个月吧，也在按照这个模式，重新构建项目，只是实体，聚合根在复杂的业务逻辑下，如何拆分和聚合，一直觉得没掌握到位。希望后续案例可以给我启发作者回复: 您说的第一个问题，尤其是数据代码类应用场景下都是存在的，这种情况下需要考虑必要的数据冗余，可以采用小表广播的方式，源端数据变了后，可以考虑异步方式广播到数据使用的目的端。 第二个拆分需要考虑限界上下文，并且保证业务的高内聚，高内聚你可以理解为原来的模块的概念，具体大小根据你的业务来定。
2019-10-15214
方堃我觉得微服务现在转型有个挺大的问题就是团队认识深度。因为现在好多项目都是先简单的以单机项目为基础开发，追求上线速度。后续发现项目越来越大才考虑进行架构方向的整理。导致很有可能出现早期只有开发产品没有架构师参与。这时候转型，架构师多久能吃透现有的业务就是转型速度的瓶颈了。毕竟产品不了解代码，开发人员又往往只盯着自己的模块缺少整体的了解作者回复: 您说的这些问题确实很常见，很多企业都是业务的归业务，技术的归技术。DDD其实也跟中台建设一样，也是一种企业和组织文化的变化，需要业务和技术融合在一起。
2019-10-1413
