06｜领域拆分：如何合理地拆分系统？
该思维导图由 AI 生成，仅供参考
案例背景
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
电商系统高并发改造的关键挑战和解决方案 本文以电商供货商系统为例，探讨了在面临高并发改造时，系统拆分、库存争抢优化和系统隔离优化等方面的重要考虑因素。作者首先描述了供货商系统中订单数据量过大、功能职能过多导致系统性能下降的问题。随后，通过具体案例展示了如何合理地拆分系统，以满足高并发和数据一致性要求。文章强调了对业务流程、角色和关键动作的分析，以及拆分出不同业务领域和聚合根的重要性。通过大胆的拆分，实现了两个系统的数据关联，简化了整体订单流程。 此外，文章还提到了系统的拆分和服务的抽象问题。作者指出，底层服务需要进行抽象，以减少变更频率，并介绍了三种抽象方式：被动抽象法、动态辅助表方式和强制标准接口方式。针对电商系统的特点，文章强调了服务的抽象程度对业务稳定性的重要性，并推荐了使用强制标准接口方式进行抽象。 总的来说，本文通过具体案例展示了如何合理地拆分系统，以满足高并发和数据一致性要求，并介绍了针对电商系统的服务抽象方法。这些内容对于需要进行系统改造和优化的技术人员具有重要的参考价值。文章内容深入浅出，为读者提供了解决电商系统高并发改造挑战的实用方法和技术思路。
《高并发系统实战课》，新⼈⾸单¥59
全部留言(9)
- 最新
- 精选
👽这节课其实个人认为应该拆分为两节：1.领域设计；2.业务抽象设计； 领域设计的核心在于，将一个很大的流程去把它尝试独立拆分使其边界明确。本文中的例子就将一个臃肿的订单流转，根据业务流程进行领域设计和拆分。使其在每一个阶段都有自己的生命周期。每个生命周期对应一个单独是核心业务实体以及数据库表。每个领域向内聚合，领域之间划清边界，每个领域业务的生命周期流转，仅囊括当前业务自己的这部分，尽量减少与其他领域过度耦合。 底层服务拆分又是另一个概念了。方法有从下到上（被动抽象），从上到下（强制标准）两个方向。从上到下是理想状态。但实际实践中还要根据实际业务来，抽离通用业务，强制抽象设计，引入公共服务总线等都是方法。业务和实际情况不是一成不变的，要根据当前的实际情况进行选择。作者回复: 感谢你的总结思考，总结得很好～
2022-12-27归属地：北京8
徐石头MVC是项目目录功能分层设计，偏框架，而DDD更多是业务实体领域和彼此之间的关系，偏业务作者回复: 你好，徐曙辉，很高兴收到你的分享，你提到的这个很有意思，这里我也接着分享一些小想法，当然这是一家之言，MVC和DDD设计的项目的目录结构也有很大不同，MVC侧重service重一些因为上面controller是endpoint，DDD侧重的是service偏RPC，所以service有些类似controller，service对接endpoint，所以内部逻辑的划分会往下压一些～那么我们再往下想想～
2022-11-04归属地：北京2- Geek4892老师，我看到的图7和图6完全一样，是放错了还是有别的意图～
作者回复: 你好，主要是想再次强调：）
2023-10-06归属地：江苏1 
阿昕思考题：1.mvc是从代码结构层面来指导分包的，使得整体代码结构更有条理；2.ddd分为战略和战术两个层面，在战略层面来讲，它采用了实体、聚合、泛化等概念来指导领域建模，让架构更贴近业务；在战术层面来讲，分包的方式比mvc更进一步，在整洁架构方面表现得更好。作者回复: 你好，阿昕，是的使用DDD这里确实会更规范，但是缺点就是DDD分包会让项目层级更多～对于小型项目会更复杂
2023-04-06归属地：浙江
严程序DDD我感觉主要是从业务流程的独立性来逐步往下拆分到最后的实体分工~它比较强调业务的独立性和低耦合度，而mvc偏向从实体出发再去拆分它的业务动作。主要还是拆分方向不同 整体的理论最终达到的目的是比较一致的~所以中间过程一些是有一致性的作者回复: 你好，严程序，并且还有个特点，微服务整理的好可以让自己的领域内的资源完全独立隔离，并且MVC更喜欢实现 内网公共服务+外网业务服务方式做成两层业务结构，但是微服务喜欢 内网公共服务+外网界面拼装业务逻辑或BFF层实现
2023-01-09归属地：湖北
奕同层级之间的模块是禁止相互调用 ------------ 这个的服务划分，同一层级的不允许相互之间调用，由上层类似于 bff 做聚合了，会不会太严格了？ 很多业务模块都会在同一层，相关之间会有依赖作者回复: 你好，一步，这个要看是贫血模型还是充血模型，同时同层也是有分层的，不能相互调用是因为会产生链依赖后续翻新改版很容易没发现出各种依赖变更问题
2022-12-23归属地：北京- Geek_994f3b我个人觉得两者只是作用域范围不同，从程序的角度看，MVC模式用在线程间(单体应用)，而DDD用在进程间(微服务)，那么MVC + RPC协议 + 业务拆分 ≈ DDD(个人愚见：)，像是在单体上多套了一层
作者回复: 你好，再补充一个细节，贫血模型，充血模型
2022-11-27归属地：北京 
花花大脸猫其实大部分问题的出现，都是由于对初始的架构设计过于理想，在迭代过程中对需求与初始架构之间的规划缺乏思考，导致后续产品的臃肿，遇见的大部分场景都是这样的原因。文中说的拆分和架构设计需要我们不定期回看、自省、不断调整。这一段恰恰是作为工程师最欠缺的部分或者说最容易忽视的部分，当有这样的想法的时候，说明已经相对是一个高层次的视野去审视问题了作者回复: 优秀
2022-11-16归属地：北京
似水年华老师的这节课对于我们面临各个业务发展周期如何合理的进行业务模块划分有了比较清晰的解答，另外一点也证实了过度设计有弊而无利。其核心的关键点是在理解业务领域模型的基础上，利用合适的方法论和工具去做业务模块合理的划分，并在抽象设计上需要把握平衡点。作者回复: 你好，似水年华，感谢支持！有任何疑问随时留言～
2022-11-10归属地：北京
