为什么要用“领域驱动设计”？ “领域驱动设计”相比于mvc/soa的优势？

领域驱动设计精简版

为什么要用“领域驱动设计”？
“领域驱动设计”相比于mvc/soa的优势？

领域驱动设计.png

领域驱动设计项目结构.png

所谓的领域， 其实就是 一个个的业务子系统。
领域驱动设计， 其实就是 “业务驱动设计”。

mvc/soa项目结构.png

领域驱动设计项目结构 vs mvc/soa项目结构

mvc/soa结构的项目， 业务逻辑集中写在了service层， 当业务变更了， 就得修改service代码， 如果原来的业务逻辑较为复杂，代码也会复杂， 修改起来是一件很痛苦的事情。

领域驱动设计：
用application代替了mvc/soa的service层， application不涉及到具体的业务逻辑， 只涉及到业务的流程。修改业务逻辑， 只需要到对应的领域对象中修改即可； 添加新的业务流程， 只需要调用相关的领域对象即可。

领域对象代码包含：
实体(Entity)、持久层访问接口、 service(用来联合多个实体对象，以及具体的业务逻辑)

也就是说， “领域对象”包含业务逻辑， 和自己紧密相关的业务逻辑， 把mvc/soa的service层的复杂度/业务逻辑 拆分到了具体的一个个领域对象中，

《领域驱动设计简化版》对以上内容的表述

当我们创建一个软件应用时，这个应用的很大一部分是不能直接跟
领域关联的，但它们是基础设施的一部分或者是为软件服务的。最
好能让应用中的领域部分尽可能少地和其他的部分掺杂在一起，因
为一个典型的应用包含了很多和数据库访问，文件或网络访问以及
用户界面等相关的代码。
在一个面向对象的程序中，用户界面、数据库以及其他支持性代码
经常被直接写到业务对象中。附加的业务逻辑被嵌入到 UI 组件和数
据库脚本的行为中。之所以这样做的某些原因是这样可以很容易地
让事情快速工作起来。
但是，当领域相关的代码被混入到其他层时，要阅读和思考它也变
得极其困难。表面看上去是对 UI 的修改，却变成了对业务逻辑的修
改。对业务规则的变更可能需要谨慎跟踪用户界面层代码、数据库
代码以及其他程序元素。实现粘连在了一起，模型驱动对象于是变
得不再可行。也很难使用自动化测试。对于每个活动中涉及到的技
术和逻辑，程序必须保持简单，否则就会变得很难理解。
因此，
因此，
将一个复杂的程序切分成层。开发每一个层中内聚的设计，
让每个层仅依赖于它底下的那层。遵照标准的架构模式以提供层的
低耦合。将领域模型相关的代码集中到一个层中，把它从用户界
面、应用和基础设施代码中分隔开来。释放领域对象的显示自己、
保存自己、管理应用任务等职责，让它专注于展现领域模型。这会
让一个模型进一步富含知识，更清晰地捕获基础的业务知识，让它
们正常工作。

领域驱动设计的优势和劣势

刚开始实现需求的时候代码是挺多的- 为了降低业务逻辑编写的复杂度；但是后期维护起来很简单。
“先苦后甜”