1.1 为什么DDD难落地？

洋葱架构图：

• DDD能解决什么问题？

其实DDD的核心是：提升业务的聚合性、提升业务的拓展性。

• DDD的错误认知？

1. 很多人首先想找一个DDD的框架来学习？

2. 学习DDD层次和DDD的领域概念？

3. DDD不适合小项目，只适合产品或大项目？

大部分人都容易陷入到四层架构和各种DDD对象的概念上出来，以为这些概念用好了就可以了，如果只是研究这些概念，那就完全错了，因为这些框架与概念都只是其表象。

• DDD是怎么来的？

我没有考证具体DDD的由来，但是我一直给很多人说，DDD其实是面向对象（OOP）的一种落地方式。

• DDD的建议学习路线？

编辑基础->面向对象->设计模式->领域驱动

• DDD初学者的两大门槛？

1. 面向数据驱动转化为面向对象驱动，业务逻辑的控制由数据库的控制转交给对象控制。

2. 理解面向对象的概念与本质。

• 开闭原则的理解？

在面向对象编程领域中，开闭原则 (The Open/Closed Principle, OCP) 规定“软件中的对象（类，模块，函数等等）应该对于扩展是开放的，但是对于修改是封闭的”[1]，这意味着一个实体是允许在不改变它的源代码的前提下变更它的行为。该特性在产品化的环境中是特别有价值的，在这种环境中，改变源代码需要代码审查，单元测试以及诸如此类的用以确保产品使用品质的过程。遵循这种原则的代码在扩展时并不发生改变，因此无需上述的过程。

代码越多越容易出现错误，所以我们要拆分，要聚合。或者说就是提升可维护性、可复用性。

拆分是指，把大段代码拆分成小段代码。其实就是层次划分与对象定义的过程。

你怎么拆分？依据（DDD）

为什么这样拆分？方法（业务聚合）

聚合是指，把相同智能的代码可以不断复用。

• 软件世界的乌托邦：

1. 不修改已有代码通过增加新的代码即可实现对功能的调整

2. 代码可被高效的复用

3. 增加新的功能只直接测试当前新的功能质量，且不会对之前的功能产生影响。

4. 非常容易的验证代码质量（单元测试的覆盖度高）

5. 代码易读性强，层次清晰，规范统一