架构分层个人理解

在刚工作不久时就对代码的分层结构感到疑问，我对分层的理解主要分为三个阶段：

• 阶段一：比如就MVC三层结构各层之间对象的对应关系及转换哪些是有必要的，哪些是没有必要的，代码结构为什么要三层？如果三层不满足怎么办，此时要不要类似像阿里规范中加一层Manager层（后来加了但不知道为什么加）？当初没有一个有经验的架构师来带，对这块的理解走偏了。
• 阶段二：自从有一天理解了使用DDD思想来对业务对象建模，才明白阿里规范中加一层Manager层的作用，但问题还是来了，有些问题还是弄不明白，比如事务放在哪一层，放在领域层还是应用层？什么是领域服务，怎么划定领域对象的职责？
• 阶段三：攻克营销系统“互动营销领域建模及实践”后，阶段二的几个问题也清晰了，也基本对代码的分层结构有了自己的理解。

基于现阶段的理解，总结出了个人理解的业务系统的分层结构，如下图：

参考上面的分层结构，有以下几点可以明确：

第一点：阿里规范中的Manager层本质上就是领域层。

第二点：事务放在应用层是最合适的，应用层涉及到业务的一个完整的编排，即一个事务的完整流程。若领域层需要事务怎么办？比如一个领域聚合对象涉及到多个对象组合，这里可以看作一个子事务来保证领域对象的一致性。

第三点：层与层的依赖关系是单向的，上层可以直接使用或操作下层元素，若下层需要与上层进行通信，可使用回调模式或观察者模式实现。

第四点：DDD提倡富领域模型，尽量将业务逻辑归属到领域对象上，实在无法归属的部分要设计成领域服务。另外，领域服务会对多个实体或值对象进行组装和编排。