DDD到底是什么？？

DDD，网上太多解释了，但都大同小异，就是解释名词的，看的发晕，我这里给出通俗的解释，助大家能理解究竟什么才是DDD。

定义
DDD，英文全称是Domain Driven Design，对应的中文含义是领域驱动设计，指的是针对特定领域进行定制化的设计。

DDD是指导思想，不是具体的实操技术，这里有一个重点需要注意，不是每个系统设计都可以使用DDD，DDD解决的是复杂问题。
那什么才算是复杂问题？？请看适用场景。

适用场景
那DDD究竟适用于什么场景，从以下几种判断：
1、系统组件是否足够多，说白了一个系统是否子系统比较多？
2、业务流程是否复杂？
3、软件生命周期是否长？这里不是指开发周期，是指软件的使用周期，是否需要长时间的维护。

举例来讲，大家可能听过或者遇到过这样的事，有一些系统可能已经完成了开发，然后运行了十几年，然后出现了一个问题，这个时候发现原先维护的人已经离职了，没有人可以维护这个系统，还需要再请原先的人来进行解决。

这个案例其实就是生命周期比较长的例子。。类似这种的就可以使用DDD来设计。

如何做?
那DDD究竟该怎么做呢？
正常逻辑是先得有人，才能做事，那么我们就按照这个思路来讲解，先讲人，再讲系统，也就是事

人的组织架构
按照正常逻辑，一般要开发某个系统，流程是如下几个步骤：
1、业务方提出需求
2、产品经理根据需求进行需求设计
3、架构师再根据产品经理的需求设计，进行系统的架构设计
4、开发人员根据开发文档进行开发

这个流程看上去很正常，但是要注意，如果是简单的系统，这样没毛病，效率也较高，但是假如是复杂的系统，这样就会出问题了。 什么问题？业务如果比较复杂，就会出现假如开发文档写的不清楚，开发人员就需要往上逐级反馈，然后在逐级回应信息。这样其实极大地增加了沟通成本。那怎么做呢。

DDD其实给了一种思路，那就是所有人员一起参与系统的整个生命周期。这样，不仅效率提高，且不容易出错。当然，这种的对研发人员的沟通要求也会比较高一些。

这里抛个问题，那如果一个系统足够复杂，谁才是最懂业务的那个人？

系统的架构设计
如果遇到一个复杂的问题，你会怎么处理？我觉得不是一上来就直接开干，而是分析一下，他复杂在哪些方面。
经验告诉我们，一个复杂的系统，不是每一块都复杂，也不是每一块都重要。所以我们可以将复杂的系统进行分解。如何分解呢？

领域驱动设计提供了一个分解复杂问题的思路，他将业务领域分为三个大类，核心领域，通用领域，支持型领域。下面我们详细分析下每一块的内容。

核心领域
核心领域顾名思义，就是指你所在的公司的核心业务，也可以说是核心竞争力。

核心领域，一般都是通过自研来进行。同时核心领域最好是把公司内部最优秀的一撮人放在这个项目组中，而且核心领域一般都会持续不断的维护来进行升级迭代，所以要做好长期的准备。这也刚好应了开头讲的内容，长期维护的适用于DDD。

通用领域
**那什么是通用领域？**这个相对来说好理解一些，说白了，就是系统中通用的组件，比如说短信平台、安全、日志等。
一般来讲，通用领域，不建议自研，而是尽量采购第三方服务提供商，一般这样性价比会比较高。
当然也会发现采购的，不一定符合自己公司的要求，那可以在
此基础上做二次开发。
同时对此类系统，不要抱有太高的要求，本着能用的心态，研发系统的时候，也要本着随时可能会替换的思路去设计。

支持型领域
支持型领域是指用来辅助核心领域的系统组件。
这么看来支持型和通用领域好像很像，很容易就搞混了，那如何区分呢？
支持型领域一般不会跨行业使用，顶多在当前行业内通用。而通用领域是可以跨行业的，在哪一个领域都可以拿来使用。
比如说，一家做电商行业的公司，股票分析系统对他可能就没什么用，因为根本没有任何共性，但是卖家系统就属于支持型的领域，因为这个系统只有在电商行业中才会使用。
而如日志、安全等，不管是在电商行业，还是金融行业，都是通用的，这块就属于通用型领域。

与通用型领域类似，支持型领域一般建议通过采购的方式来进行，如果市场上没有此类产品，那么建议通过人工处理，如果一定要自研，同样道理，保持能用、随时会替换的态度的就行。

举例
这里举个例子来把三种领域说明一下。
比如说一家公司是做高校校园卡业务的，
那么他的核心领域就是校园卡相关，比如校园卡管理系统，卡账户系统、交易系统等等。
那通用领域自然是日志系统、报表系统等，可能还会有对公司自身的OA系统等等
那支持型的领域可能就会有教职工信息管理系统，学生管理系统等，这个是在当前高校领域中单独有的。