01 | 领域驱动设计：微服务设计为什么要选择DDD？
软件架构模式的演进
请订阅文章所属专栏。
精选留言(66)
Geek_a91670 置顶事件风暴到底是什么啊?作者回复: 后面章节会有一章专门讲，会有一个案例。跟头脑风暴类似，通过它设计领域模型。
2019-10-21 2
halweg我能说我等极客时间出这个等了1年吗？编辑回复: 忠实老粉了啊～期待你的打卡！
2019-10-14 6 22
Dr实战源代码，成体系吗？还是散落在文章里面？有的话，哪里可以下载？理论看了很多，缺一套代码，琢磨琢磨。作者回复: 选了一个企业级的中台设计，从领域建模到微服务设计选取了几个典型的中台，过程基本是完整的。最后的示例，源代码只到服务和实体类级别，里面具体业务实现代码没有。也就是说微服务整体架构的框架搭起来，但没有往里填肉。
2019-10-14 2 4
斯图尔特这里提到的业务人员是指？还有领域专家。套用公司场景，一个做企业服务，tob的公司，有自己的产品。这个过程中，有客户的需求，有项目经理的梳理客户需求。有产品经理对系统的规划，有客户成功提交的使用优化。这个过程中参与人，客户，项目经理，产品经理，客户成功。人员参与，那这些人在DDD领域模型的角色是？作者回复: 斯图尔特，你好。
领域模型里面都是一些领域对象，这些领域对象是构成系统的一些业务行为。你说的这些角色不知道是不是指系统建设过程中的角色。其实DDD并不改变原来软件开发过程中的角色，只是工作模式发生了变化，大家一起设计领域模型，设计微服务。领域专家是熟悉并深刻理解这个领域的人，可能是业务人员，也可能会是产品经理，甚至可能是开发人员。传统企业一般有信息和业务一说。业务人员一般是指业务部门的人员。2019-10-15 3
THDDD是针对业务的，那么到底怎么理解“业务”呢？什么属于业务，什么不属于业务呢？尤其是业务与技术、基础设施、中间件之间的关系怎么划分？
换句话说，DDD是否适合技术框架、技术平台甚至技术中台的建设呢？比如我要开发一个代码部署系统或者配置管理系统，这样的系统是否适用DDD呢？因为对整个公司来说它们应该属于基础设施层的东西吧。
DDD是否存在大系统套小系统的形式？比如整个公司业务用DDD来设计，然后业务中的某个子系统也用DDD来设计，它们可以嵌套吗？作者回复: DDD包括战略设计和战术设计，战略设计主要面向业务完成领域建模，战术设计是根据领域模型完成微服务设计的过程。领域的概念应该包括您所说的代码部署系统或者配置管理系统，只要能在这些领域中能够提炼出领域模型就可以。
2019-10-15 3 3
Geek_9695b4我们公司现在也有这方面的想法，但是一直无从下手，主要原因是，
1、我们是给工厂做软件的，不同的工厂相同的功能需求会有有差异，这个怎么解决？显然一个工厂一个版本是不好的
2、不同工厂需要使用不同的数据库
3、功能模块主要有物料管理、订单管理、计划管理、出入库管理、库存管理等，里面功能模块较多
4、DDD怎么更好的去解决SAAS化的产品研发问题作者回复: 第一个问题，我想知道不同工厂软件需求的差异主要在什么地方？如果差异在流程和服务编排，DDD的分层架构应用服务很合适。如果领域层业务逻辑差异不大的话，就比较好解决。个人感觉领域层的核心逻辑差异应该不会大。
第二个问题，DDD数据库方面采用依赖倒置的方式，实现业务逻辑的时候，不会有数据库方面的逻辑，都是领域对象的行为，数据库相关代码在仓储实现中实现。也就是说业务实现与数据库是松耦合的，换数据库的时候，只需要换仓储逻辑就可以了，不会影响核心业务逻辑。
第三方问题，你说的这几个子域相对清晰，直接在子域做事件风暴，建立领域模型，设计微服务就可以了。
第四个问题，见以上三条。总之，保持领域层领域模型的稳定，用应用层去适配外部需求的变化，用户接口层面向不同渠道提供个性数据服务。2019-10-25 2 2
小明为什么soa架构会使得系统变得臃肿，可扩展性和弹性伸缩性差。我们公司以前是soa,也是拆了订单,活动,商品,拼团打折,仓储,物流,会员中心等等服务,我们也没用到总线,webapi包了一层,客户端(安卓,ios,pc)调用,api聚合服务,我想请教下1.这种设计跟微服务的区别.2.可扩展性为什么差了.作者回复: 传统SOA架构基本是单体模式，也就是集中式架构。因为需求会越来越多，系统会越来越庞大。系统大了后就不太方便放到容器之类的环境上，只能用weblogic之类的中间件，靠手工来运维了。
2019-10-29 7 1- Randy Liu关于两层边界，聚合虚边界，限界物理实边界，很有启发，也给我一直困惑的，如果一个业务领域中，有多个聚合根的情形下，更加清晰与更好的理解。
作者回复: 边界清晰了，以后微服务的演进就相对简单。一般来说聚合内部的功能都是核心的领域逻辑，是一些相对原子化的业务功能，受外部影响比较小。所以在微服务演进时可以以聚合为单元来进行微服务重组。
2019-10-21 1 
咸鱼大翻身公司最近也在准备对已有的业务拆分业务领域，希望作者能早点讲实战，对于这块特别是事件风暴方法作者回复: 很快就到了，耐心等待哈。
2019-10-20 1
肖大保健目前公司用的是spring boot 框架，根据业务也做了明显得服务拆分（接单web，调度服务，订单服务，用户服务，资金服务，api服务 等），后期打算把数据层（mysql，mongo，redis）单独拆分出去，web层controller再单独拆分做HA 或者 ng，不知道算不算的上微服务架构，我们在做服务拆分，功能聚合这块是按业务模块来的
问题一：服务的功能界限该如何划定（按功能，还是按业务，有点矛盾）
问题二：服务调用，横向一个个调用，还是按web或者调度中转，比较好？（也存在争议）
问题三：文章中提到界定上下文，请问在服务中该如何体现，不是很明白作者回复: 你说的这几个问题我后面都会讲到，耐心等待哈。
第一个问题：会通过事件风暴来建立领域模型。
第二个问题：前后端分离后，可通过API网关调用后端微服务，或者对于复杂的业务场景可以考虑在前端与后端微服务之间增加一个BFF的微服务，可以对多个微服务进行服务组合和编排。
第三个问题：限界上下文边界理论上就是微服务的边界。2019-10-16 1
陈华应第一个接触ddd的服务是在leader带领下及自己恶补啃ddd砖头书的情况下完成的，收获就是有了点ddd的思想，但是现在对整体和细节都存在理解不清的地方。后面多结合老师的课做回顾和请教~作者回复: 一起学习和进步哈。
2019-10-15 1
酆友鹏听说过，一直不知道怎么去实践DDD作者回复: 专栏里面会有详细的过程介绍，先理解概念，然后学会怎么用事件风暴建立领域模型，根据领域模型来设计微服务。等着后面的实战篇哈。
2019-10-14 1
Leiy在开始微服务拆分的过程中，碰到两个问题:
1.项目组开发人员对业务的理解不同，对于有些聚合是放在哪个限界上下文中会产生分歧
2.对于一个庞大古老系统，拆分是开始时候就拆分的较细，还是先拆分两个核心业务域，后面再逐步拆分作者回复: 很多的时候领域的细分会根据业务流程阶段或者模块功能，这两个方面业务有很好的内聚性，很可能就对应到了子域。如果领域实在太大，你可以考虑将它分成小的领域，然后在这小的领域中去做事件风暴，划分限界上下文，并确定哪些聚合放在哪个限界上下文里，这里领域专家会起到比较大的作用。不过建立领域模型后，你还需要看看其它子域是否有重叠的内容，如果有的话，还需要对领域模型重组。
2019-10-14 1 1
方堃我觉得微服务现在转型有个挺大的问题就是团队认识深度。因为现在好多项目都是先简单的以单机项目为基础开发，追求上线速度。后续发现项目越来越大才考虑进行架构方向的整理。导致很有可能出现早期只有开发产品没有架构师参与。这时候转型，架构师多久能吃透现有的业务就是转型速度的瓶颈了。毕竟产品不了解代码，开发人员又往往只盯着自己的模块缺少整体的了解作者回复: 您说的这些问题确实很常见，很多企业都是业务的归业务，技术的归技术。DDD其实也跟中台建设一样，也是一种企业和组织文化的变化，需要业务和技术融合在一起。
2019-10-14 1- 瓜瓜如何用DDD解决复杂业务的架构问题，一直在等这方面的相关课题
作者回复: 希望能对你有帮助。
2019-10-14 1 
素丶同等一年编辑回复: 姗姗来迟～莫怪莫怪！
2019-10-14 1
卡特公司不停的在做市场探索，新项目基于微服务架构，基于业务建模，结合团队规模拆分微服务，正缺少相关领域设计理论支持。作者回复: 正好可以用上^_^。
2019-12-09
番茄炒西红柿第一章抛出好多名词感觉有点看不懂，希望后面会好点😭作者回复: DDD名词是很多，前后稍微多看几遍吧。
2019-11-22- caozhaoDDD不但可以应用在微服务中，还可以使用在单体应用上，很期待2019-11-20
krugle电商saas 那个是核心域 订单还是 商品作者回复: 每个企业都不太一样的，跟商业模式和战略定位有关。个人感觉在电商领域，订单和商品是比较通用的业务能力，偏通用会多一些。
2019-11-17