15 | 边界：微服务的各种边界在架构演进中的作用？
该思维导图由 AI 生成，仅供参考
演进式架构
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
微服务架构设计中的边界在架构演进中扮演着关键角色。逻辑边界强调业务内聚，物理边界关注微服务部署和运行的隔离，代码边界强调代码之间的隔离。清晰的边界有助于实现微服务代码的拆分和组合，但需注意避免大单体向小单体的演进。在实现微服务的架构演进方面，需要注意边界的清晰性，以支持增量的、非破坏的变更。与DDD设计方法相比，微服务架构更注重边界的物理和代码隔离，而DDD更注重业务领域的建模和设计。在选择哪种方式更好时，需要结合具体业务场景进行分析。
《DDD 实战课》，新⼈⾸单¥59
全部留言(28)
- 最新
- 精选
清涧飞鸟老师，这节课程看了好几次了，但是对于几个概念还是有点朦胧，您帮我判断下以下我的几个说法： 1）一个聚合可以看作为子域 2）一个限界上下文可以作为子域 3）聚合是最小的边界 4）限界上下文内可以包含一个或多个聚合 5）领域模型是一个子域、一个限界上下文、一个聚合？？或者都可以，只要可独立为微服务的就可以叫一个领域模型.作者回复: 在DDD中如果领域很大的话，内部由小到大的顺序大概是这样的：值对象-》实体-》聚合（最小业务功能单元，如果非常必要可以拆分为微服务）-》限界上下文（一般作为拆分为微服务的依据，包含一到多个聚合）-》子域（包含一到多个限界上下文）-》领域（包含支撑子域、核心子域或通用子域等一到多个子域）。 在有些情况下，一个子域可能就是一个限界上下文，一个限界上下文可能只包含一个聚合。一般来说，在一个限界上下内来构建领域模型，一个领域模型可以设计出一个微服务。 服务的从低向上关系是这样的：实体方法-》领域服务-》应用服务-》Facade接口。 不知道是否清楚了？
2020-05-28446
密码123456之前2个月前，要做微服务，当时不了解是啥，就感觉好厉害。然后按照业务划分。最后做成的结果，就像文中说的。大单体变成小单体。，高度耦合。做的自己都快看不下去了。作者回复: 在没有用DDD之前，我们也是这么干的^_^。
2019-11-18521- 开心小毛请问老师，为什么再给出的例子中会出现某某工厂类（leaveFactory）呢？ 是用来从数据库中读取并创建leave实体的么？如果是的话，为何不在leaveDomainService类中加一个GetLeave方法呢，不知leaveFactory有何必要。 是用来从数据库中插入并返回新建leave实体的么？我一直是通过DTO中的ID是否为零来判断是否为新建实体的，不知leaveFactory有何必要。 谢谢老师解惑。
作者回复: 看看这段话能不能解答你的问题。 聚合中实体和值对象等DO对象的创建和持久化是聚合必不可少的操作。为了保证聚合内数据在修改时符合聚合业务规则要求，聚合内实体和值对象在创建和持久化时，需要遵循聚合统一的业务规则。 对于实体和值对象比较多和依赖关系复杂的聚合，在DO对象创建时，需要确保聚合根和它依赖的对象实例同时被创建。如果将这项工作全部交由聚合根来实现，聚合根构造函数的逻辑将会非常复杂，聚合根也无法聚焦于自身的领域逻辑。 为了让聚合根专注于表达领域模型，我们尽量将这些比较通用的，与领域模型业务逻辑无关的工作，从聚合根中剥离。将它们放到工厂（Factory）中实现，通过工厂封装聚合内复杂对象的创建过程，完成聚合根、实体和值对象等DO对象的创建。这样也可以隐藏聚合内DO对象的创建过程，避免暴露聚合的内部结构。 聚合内DO对象创建的初始化数据来源于PO对象，PO对象是仓储从基础层获得的。在工厂服务中完成DO对象构建和从PO到DO对象的数据转换，完成DO对象的数据初始化。 除了构建DO对象，在将DO对象持久化时，还会有从DO对象到PO对象的转换，这类通用的持久化对象的转换操作，也可以放在工厂实现。 但并不是所有聚合对象的构造都需要用工厂来实现。如果聚合内领域对象简单，构造过程也并不复杂，你仍然可以用聚合根构造函数，完成聚合所有依赖对象的构建和数据初始化。
2020-05-09414 - 秦伟老师，我们正在做组件化，公司架构师说只对核心领域用ddd设计，其他的还是安三成架构开发，这样可以吗？
作者回复: 可以的，一步一步来。
2020-04-018 
alex欧总，你好，我在拆分微服务时遇到一个好纠结的问题，例如三个微服务，分别是入库微服务，出库微服务，库存微服务，而库存微服务主要提供两种能力，一是：查询库存，二是：更新库存数据，而入库服务与出库服务都会在自己的业务逻辑内调用库存服务的“查询库存”和“更新库存”方法，为了避开分布式事务的场景，我们现在用的方案是在入库，出库的操作时，通过接口形式调用库存服务的“查询库存”接口方法，但当要在入库或出库操作步骤中要更新库存数据时，我们为了保证入库操作与库存更新在同一个事务内执行，达到事务一致性，我们通过引用库存服务对应的jar包形式，在入库和出库的服务代码中调用库存服务模块的“更新库存”的service方法来实现的，请问对于这种场景，你们有没有遇到，如果有，那你们是如何处理的？请指教，谢谢。作者回复: 感觉你这种方案也没法解决数据一致性的问题。一般来说产生数据一致性的主要原因在数据库，也就是说一个写成功，另一个写失败。虽然JAR包和业务执行逻辑在一起了，但是由于数据库是分开的，在数据库层面还是无法保证数据的一致性的，所以虽然它们在一个jar包中，应该还是需要采用分布式事务的。 我们没有遇到过你说的场景，但是这个场景应该在电商里面是非常常见的，比如查询商品数量，商品售出后，更新商品库存数据。
2019-12-22103
Eric在同一个微服务内的应用层使用领域层的服务时，数据传递建议使用哪种类型的对象呢？是用DTO还是DO？ 如果因为性能问题，讲应用层对领域服务的调用从微服务内调用改为跨微服务调用（例如RESTful或者RPC），那么调用接口传递数据是否使用DTO比较合适？作者回复: 应用层与领域层之间是DO。 微服务之间用DTO比较合适。
2019-11-222- 玉宸道君我刚刚加入的一个公司，现在拆分的微服务代码结构就是“小单体微服务”。并且其中多个服务的业务都有评论、点赞这些操作，于是他们把评论、点赞单独抽取到了一个微服务中去了。我觉得这样的拆分方式是把自己的业务给拆分出去了，这样的微服务不是业务高内聚的。打个比方，这样拆分的微服务，就像一个只有自己身体的躯干部分的人，手、脚不在自己身上，做事情的时候还需要临时去找手、脚。接口内部微服务间调用变多了，对接口的可靠、性能都造成影响。 不知道老师对我说的情况有什么看法呢？
作者回复: 从单体到微服务肯定是有代价的，需要有相关的设计方法论指导，规范和降低服务设计、开发和集成的复杂度，还有诸如分布式架构下的一些设计理念也是需要掌握的。比如如何通过数据冗余，比如值对象，避免跨微服务的数据访问，如果通过领域事件驱动的方式实现聚合和微服务之间的解耦等等。 如果单体应用完全可以满足业务要求，也可以不转成微服务。但是目前由于基础环境的变化，比如云计算，微服务比单体应用有更强的适应能力，更容易上云，生态也更齐全，所以从单体到微服务是未来的趋势，这就需要掌握一套好的设计方法。
2020-11-1621 - 0084有些项目团队在将集中式单体应用拆分为微服务时，首先进行的往往不是建立领域模型，而只是按照业务功能将原来单体应用的一个软件包拆分成多个所谓的“微服务”软件包，而这些“微服务”内的代码仍然是集中式三层架构的模式，“微服务”内的代码高度耦合，逻辑边界不清晰，这里我们暂且称它为“小单体微服务” 我们公司2017年中开始用SpringCloud全家桶搞微服务，目前的现状和老师讲的小单体微服务一摸一样，每个微服务中的代码还是按照传统三层架构设计。比如有客户系统、影响系统、消息系统、支付系统、账务系统等
作者回复: 这种情况应该很常见。在没有接触到DDD之前，很多企业可能还是在按照三层架构模式进行微服务设计。在理解了DDD的核心设计思想后，你会理解ddd的方法在微服务设计中还是很有前瞻性的。架构设计中“高内聚，低耦合”强调了很多年，这个原则基本会一直延续下去。DDD虽然早于微服务很多年出现，其根本目的就是为了“高内聚和低耦合”和实现架构轻松演进。
2020-08-3121 
王海林老师，能进一步说说，逻辑边界与微服务API设计的原则吗？感觉这似乎是结构优雅与否的关键。作者回复: 是的，要保持逻辑边界的清晰，就必须保证聚合之间的松耦合。松耦合有两个问题要避免：一是不同聚合的领域服务之间不要直接调用；二是不同聚合之间的DO实体或持久化实体之间不要产生表级关联，这样在从逻辑边界变成物理边界过程中就不需要进行太多的解耦的操作了。 如何结合聚合之间的服务调用呢？ 聚合之间的领域服务调用可以上升到应用层，通过应用服务来组合和编排不同聚合之间领域服务，实现不同聚合之间的服务协同。在应用服务组合编排不同聚合的领域服务时，要尽量避免在不同聚合的服务调用时的对象传参方式，因为这样也会产生聚合之间的对象耦合。
2020-06-1121
妙手空空领域服务之间能互相调用吗？作者回复: 理论上可以，但不建议聚合之间的领域服务直接调用，主要是为了聚合之间的解耦。你可以将这种聚合之间的调用，上升到应用层，通过应用服务来进行编排和调用。
2020-04-191
