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