现状
现在后端的应用开发习惯于MVC的编程方式，基于数据模型去设计和开发软件，遇到一个需求，分析后先设计数据库的表结构，再为这个数据模型编写对应的处理逻辑， Controller/Service/Dao，这其实有些本末倒置。会产生如下的问题
- 由于是先设计的表结构，业务逻辑要以数据库中的表为基础，导致编码逻辑和现实的业务逻辑偏离较大，代码除了原作者很难看懂
业务稍微复杂一点，就会导致Service 存在大量的分支和逻辑，导致Service更加难以维护，Service 之间的耦合越来越高
软件设计中者和真实的业务专家沟通困难，很多是针对功能设计，而不是针对业务流程和价值的设计
- 项目文档难以管理，敏捷提倡少文档化，那如何输出研发人员和业务专家否能看懂的文档呢？并且敏捷也提倡代码即文档，什么样的代码可以的更简单易读，贴近业务呢？
DDD介绍
而DDD作为一种大型软件开发的方法论可以有效的解决这些问题，以下是DDD的几个核心的思想
沟通：和领域专家统一关键的名词和术语，以达到高效和无障碍的沟通，充分理解领域专家要表达的意思，消除语言上的鸿沟
设计：使用全局化的思维去设计，有宏观到微观， (战略设计->战术设计) ，通过不断细化和优化模型，找出系统核心领域和逻辑。一般一个系统的核心逻辑是不会发生大的变动，比如银行的核心就是账号收入和支出，仓库核心就是货物出库和入库。这样就可以很大程度上固定了核心领域，减少系统需求变动对系统的伤害，大大降低系统的维护成本。 而系统的维护成本在整个生命周期汇总占了很大一部分
知识：提倡大家共同学习，提炼知识，在讨论中设计出最优化模型，这是也是敏捷最关注的环节
价值：DDD的价值在于团队知识共享，共同设计出切合实际的模型。大量减少项目维护的成本，简化了项目交接中的知识传递
那为什么现在DDD没有那么流行呢？
- 任何事情都需要成本，要使用DDD开发一个易于维护的项目需要额外的成本，而目前国内人力充足，相比于时间成本人力成本更加的便宜，所以很多公司有优先选择短期内见效快的方案。
- 对软件人员要求高，要求每个人开发人员学习DDD开发模式，业务专家要尽可能的参与项目的整个过程,敏捷只是要求用户和业务专家参与项目代码规划会议，迭代评审会议 而 DDD要求和业务专家一起建模
- DDD适合大型项目，如果是一下简单的CRUD系统，那当然是没必要。
如何在组织中实践DDD，并产生价值呢？
评估项目 ，评估项目主要有以下几个方面
- 项目的生命周期，项目规划运行多少长时间，产生多少收益
- 项目的复杂度，项目的业务流程是否很负责， 涉及范围是否很广
- 项目的预算是否满足要求
- 项目中人员的素质评估
- 项目生命周期
获取支持
- 获取项目Owner的支持，需要进行DDD讲解，从项目收益和后期价值给Owner 讲述DDD价值和作用
人员培训
- 培训建模方式 例如事件风暴，如何画建模图，如何建立统一语言词典，以及代码分层框架的搭建，如何进行的单元测试等等
规范流程
- 结合敏捷流程，制定一个基于DDD的建模和项目流程 包括会议，建模方法，文档规范等等。
如何的评估价值？
这是一个好问题 容我考虑一下
书中的一些概念
解释性模型
MODEL-DRIVEN DESIGN
决定一个对象是Entity还是Value Object 主要看系统的定义 如果在系统中需要唯一标识这个对象那这个对象就是Entity 否则就是一个Value Object
通过重构加深理解
SIDE-EFFECT-FREE FUNCTION
INTENTION-REVEALING INTERFACES
方法不要产生副作用
尽可能把程序的逻辑放到函数中，因为函数是只返回结果而不产生明显副作用的操作。严格 地把命令（引起明显的状态改变的方法）隔离到不返回领域信息的、非常简单的操作中。当发现 了一个非常适合承担复杂逻辑职责的概念时，就可以把这个复杂逻辑移到VALUE OBJECT中，这 样可以进一步控制副作用。
开闭原则，修改和查询分离