为什么要学DDD？为了晋升和面试。

请原谅我如此直白，在专栏开始之前，我们先确定一些基础概念，打破一些看似正确的认知。

1：DDD真正的价值在哪？

这个概念基本都很统一，DDD真正的价值在于战略设计上面，再说简单点，它对P7级别包括以下的人，用途并不大。战术设计反而是可有可无的存在，即便做不好也无关大局，实现方式更是五花八门，这正是大多数人都学不好的原因---每个人做的好像都不一样！但是，作为普通开发，战略方面跟我们一点关系没有，只能盯着战术设计，也就是具体怎么落地代码去看。但是哪怕我们只用战术设计落地，也绝对比普通人强的多的多，因为大多数人还只停留在概念上。

2：为什么DDD这么难落地？

一来因为没有具体案例能参考，二是想的太多，却没有动手实践。一开始我被卡了半年也不知道怎么做，直到后来被迫必须要做点东西出来，就做了一版。当然，做的烂的一塌糊涂，不过有意思的是，在迭代中我知道哪烂了，哪过度设计了，经过近1年的调整，慢慢有一点样子了。

当然，最大的原因就是那一堆乱七八糟的概念，实体，领域，值对象等乱七八糟的东西让我一时之间不知道从哪下手，也不会分析什么代码该放在什么地方。最后的解决方案很简单，不要想那么多，先找一个稍微复杂的流程做，其他原封不动，你就盯着这一个流程思考，无论做成什么样，只要不影响功能，直接上线，再慢慢迭代。

3：普通开发能不能用DDD？

能！尽管严格意义上已经不算了，但是只要做，就有的聊。对于高P来说，DDD是用来拆分微服务的指导思想方法论，对于低P来说，DDD就是规范和内聚。我用一个简单的例子解释下，拼多多都玩过吧？假设邀请3个送奖品1，邀请5个送奖品2，要求你做一个根据邀请人数返回应该发放的奖励的方法，会怎么做？

初级开发可能会在当前类直接开一个方法，写个计算方法。缺点是不容易复用，另一个开发根本不知道你在这写的有方法。

中级开发可能会知道单独抽出来一个计算奖品的类，以便其他地方复用。缺点是当你离职了或者换到其他团队了，其他人还是不知道有这个类，可能依然会创建一个新的计算类。

DDD开发者会直接在奖品实体内做这个计算方法，任何开发者在进入团队之前都会要求认识你的领域模型，以及整套规则。所有功能高度内聚，甚至新人只要读了DDD业务白皮书，对着你的模型就能知道有哪些业务功能。

4：DDD规范一定要遵守吗？

你可能听过典型的几个层，接口层，应用层，领域层，基础设施层。不过不要紧，你完全可以忘掉这些概念，不要纠结缓存是应该放在基础设施层还是应用层。贴合你的业务来就行，哪怕他不伦不类，只要开始了，一定会越来越好。

5：DDD是什么？

首先我们看下DDD的名义解释：DDD 是一种处理高度复杂领域的设计思想，它试图分离技术实现的复杂性，并围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解，难以演进的问题。DDD 不是架构，而是一种架构设计方法论，它通过边界划分将复杂业务领域简单化，帮我们设计出清晰的领域和应用边界，可以很容易地实现架构演进。

说人话就是：作为拆分微服务的指导方法。

如果你没有经历拆服务的痛苦，可能确实很难体会到它有多难。拆少了发现没什么用，业务还是耦合在一起，拆多了更恐怖，每个人身上都背着近10个微服务，一个系统最后能有上百个微服务。只能在踩坑之后才知道应该怎么拆，DDD就是为了在不踩坑的情况下尽量合适的指导拆分微服务。

ok，我们开始学习。