很多软件设计上的不足，表面上看，似乎是技术架构的问题。因为如果架构师经验足够丰富，就能提前考虑到这些问题。如果开发团队技术足够过硬，就可以最快速度解决这些问题。但是，如果你将视野放开，放到到整个项目团队。你就会发现，一味的要求技术人员能够未卜先知，这是不现实也是不理智的。尤其对于长期建设的大型项目，更是看如此。难道你要求当年开发淘宝时就要支持好双十一吗？DDD希望让整个软件团队都用统一的方式思考解决问题，减少架构师、程序员、产品经理、测试人员等各个参与角色之间的分歧。
两个非常核心的思想：
- 技术主动理解业务
- “刚刚好”解决问题
- Controller、Service等概念并不具备实际的业务价值。因此，业务专家设计出来的业务流程，总是需要产品人员进行梳理，以及技术人员设计才能最终落地到项目当中。而这其中，不可避免的会产生信息不对称的情况。尤其在面对频繁变化的复杂业务时。
- 比如业务专家看到的是消息转发、历史请求管理、应用注册管理这三个业务能力，不管多复杂的业务场景，基于这三个能力进行组织就行。但是在技术人员的视野中，却显然更关注MVC的三层架构。会更注重Controller、Service这样一个个技术层面的逻辑分工与复用。当业务需求发生变化后，业务专家考虑的是如何通过这三种业务能力将整个业务场景贯穿起来。而技术专家往往会更多的考虑新的结构对以往的架构有多大的冲突。如果新的设计对已有的架构造成太大的冲突，就只能考虑重构。而重构对于业务专家来说，没有什么业务价值。
- DDD则是主动强调让技术贴近业务，鼓励形成团队内部的通用语言，业务如何组织，软件就如何构建。让不怎么懂技术的业务专家也能主动参与到软件建设的整个过程当中，而不仅仅是前期的需求设计。
- 在DDD的实践过程当中，有很多技术人员容易陷入以往的技术思维中，将DDD理解成某种技术架构，将组件描述成技术实现（用原来技术架构硬套在DDD上，改了个包名而已，领域专家看了依然是一脸懵逼）。相反，更应该体现业务属性，让领域专家看到这样的组件，即便不了解实现细节，也能够知道这些组件是干什么的，从而有可能继续深入的参与软件建设过程。
- 在以往的设计过程中，为了更多的兼容日后的需求变化，技术人员往往会做很多的“提前设计”。寄希望于这些“提前设计”能够减少未来业务变化对软件架构的冲击。但是，往往项目未来的需求变化并不是技术人员能够把控的。如果未来的业务需求不是按照之前设计的路线演进，这些“提前设计“不但无法起到设计时的作用，反而会增加软件项目的复杂度，从而给软件后续的升级改造带来更多的负担。而DDD强调的则是让软件可以”刚刚好“的解决眼前的业务问题，同时为软件保持足够的灵活性。
- 以DDD中的Repository仓库组件为例。在DDD设计中，我们会将实体的持久化逻辑全部交由仓库组件负责，在业务流程中不需要考虑持久化相关的逻辑。当我们需要设计更复杂的持久化策略时，就只需要调整仓库层的实现，而不需要考虑业务上有什么影响。比如，往往很多项目在最初的设计中，都会选择将关键业务信息通过MyBatis这样的框架直接存入到数据库。但是如果软件的并发量逐渐增大，往往我们就需要增加一个Redis缓存层，用来保护数据库，提高系统的并发能力。而围绕Redis缓存，各种缓存穿透、缓存击穿、缓存雪崩、缓存预热等等这样的一些业务逻辑就自然而然的冒出来了。这样一个简单的MyBatis就不够用了。如果没有抽象出Repository仓库层，那么这些新增加的逻辑就不可避免的要蔓延到上层的DAO或者Service当中。但是，如果抽象出了Repository仓库层，不管多复杂的持久化逻辑，都只是一个仓库实现而已，不会对业务造成任何影响。这些需求就可以比较独立的进行改造。
