ddd的思考

ddd到底解决了什么问题？我们为什么非要学习ddd，是否是在项目中一定需要使用到ddd设计思想了？
问题1：ddd到底解决了什么问题?
从我的理解来看，ddd的最大的作用是规定了业务的边界，这个业务的边界是通过什么来体现的了？
我的理解是通过实体对象或者是聚合根对象来体现的。也就是说，**所有的业务逻辑的实现应该是全部都是需要放到实体对象中或者是聚合根对象中来实现的。**分散到外部的话，对应的是不符合ddd的设计思想的。这种思想，天然的话，就会归拢了核心的业务逻辑的。
问题2：ddd解决了业务所有的问题吗？
从我的理解来看，ddd并没有解决所有的业务问题。ddd的初衷并不是解决业务相关的所有问题，其解决的是核心的业务问题，关注的也是核心业务问题。于业务相关的安全，审计，日志等的附属的业务细节是不关心的。这些安全，审计，日志等的操作，我理解对应的应该是需要放到应用层来解决的。接口的入参以及出参的校验问题的话，应该是需要放到接口层来做处理的。
问题3：ddd是技术实现还是业务实现
ddd出现的核心是解决业务涉及到的问题的，其并不是一个技术解决方案的，ddd的核心是业务驱动开发，最为核心的是业务层的设计，或者说是领域模型的设计问题的，因为领域模型对应的就是抽象的业务实现，当然也定义了业务边界的。ddd的使用自然而言的需要如下的两个重要人员的参与：
1）业务人员的参与，或者说是领域问题专家的参与；
2）熟悉业务，并且能够将业务转化成为领域模型的技术人员的协商和参与。
所以，ddd是一种业务解决方案，而不是技术解决方案的。ddd更多的关注的是业务实现，其核心思想是以领域模型的设计来驱动技术的实现。
问题4：ddd开发的步骤应该是什么样的？
ddd设计的核心应该是领域问题的建模，也就是领域层的实体或者是聚合根对象的设计的。领域层的设计决定了整个服务设计的好坏，领域层的设计决定了业务的编辑以及交流方式的。
问题5：ddd的优势可以得到充分的体现吗？
从我的角度而言，ddd的特性在当前阶段不能得到很明显的具体的实现，主要的原因在于下面的几点：
1）领域模型的设计是一个反复推敲和设计的过程，这个过程是需要经过深思熟虑的思考的，必然对应的是一个很费时间的活动的，在当前的环境下，以产出来恒定工作效率的情况下，这种活动不可能产期持续的进行；
2）领域模型的设计需要的是领域专家的参与，领域专家必须是精通技术和业务的人才，这种情况在当前的中国几乎没有。因为，企业不可能培养这种无法替代的人才的。同时精通技术以及业务的人才并且能够无损的将业务转化成为技术的人才，几乎没有。
3）ddd的优势的体现需要足够大的服务和项目来体现的，单个的项目或者是极为简单的项目而言，ddd的优势并不能得到充分的体现的，就好像是单体项目或者是分布式项目而言，ddd的这种优势很难凸显出现。
4）当前阶段ddd的优势主要体现在什么地方：当前的ddd更多的优势体现的是业务的聚焦，业务聚焦带来的优势是可以很方便的解决业务的持续开发运维的问题，这是我认为ddd当前最大的优势体现。
问题6：ddd模式需要大规模的聚焦和推广吗？
在了解这个问题之前，需要找到ddd最适合解决的问题以及场景。个人认为，ddd适合解决的是超大规模或者是超级复杂的业务场景，这种场景最终的体现在哪个地方？是否是一定需要这种ddd设计？
首先需要解决的一个思路是这样的，对于超级复杂的技术或者是业务场景而言，我们首先需要考虑到的是这种场景能不能分解为小的易于解决的场景，逐步的解决小的业务场景最终来解决大的负责的业务场景，所以，在这一方面其实ddd的优势得不到很充分的体现的。
但是，ddd的我认为最为核心的优势，解决了业务聚焦或者说是业务运维的问题，这一点在大的项目中是值得肯定的。对于大项目而言，业务的持续的运营和维护的难度是很大的，ddd的优势对于解决这种问题是很有作用的。
综上：ddd在我个人看来，ddd主要的是作为一种业务解决方案，而不是技术方案，更加能够凸显优势的。
1.ddd更加适合的场景是大规模或者是复杂项目的运维或者是持续迭代维护问题的。在这种场景下面能够得到较好的体现的。
2.还存在另外的一种场景，那就是解决超大问题或者是场景的划分问题，确定超大问题如何划分为小的问题并且解决小问题的边界和交互方式方面，存在优势。