作者简介:胡正军，御家汇架构团队负责人，坐标湖南长沙。开发，运维，测试，大数据均有负责，杂而不精。乐于复杂系统重构，拥抱DDD
上一篇文章说了小团队也能做中台，里面提到我们用了领域驱动设计（DDD）这个方法论来开发中台，本文对我们为什么使用DDD做一个分享，下一篇再讲我们怎么实践的DDD。
DDD出现得很早，2004年Eric Evans就写了《领域驱动设计：软件核心复杂性应对之道》，但使用并不广泛，拿长沙这边来说，使用的企业可以说是寥寥无几。
最近几年DDD随着微服务反而火了一把，各种技术群里一言不合就DDD，也有一些在线培训和书籍出版，比如人保的架构师欧创新就在极客时间开了专栏，预计本月还会出版一本书籍。然而大家虽然谈论得多，真正落地的少。
我认为原因有:
< 1 >系统不复杂，没必要用DDD;
< 2 > DDD概念多，理解难，懒得去学;
< 3 > 就算一个人学了也没用，需要团队都用起来，由于人性本懒惰，DDD对业务和开发都要求有点高，所以不想做，还是CRUD爽点。
DDD是为了解决复杂业务系统构建的一套方法论，有战略设计和战术设计两大块。战略设计的核心是统一语言和限界上下文，战术设计的核心是独立领域逻辑层。
复杂业务系统为什么要用DDD，可以从3个维度来说明。这3个维度分别是软件开发过程，复杂系统设计，模块编码。
可以看到这3个维度是一级一级降低维度的，软件开发过程涉及多个岗位（产品经理，开发，测试，业务运维），属于开发流程这个维度，复杂系统设计涉及的岗位是架构师或者高级开发，属于架构设计这个维度，模块编码涉及的岗位主要是开发了，属于代码编写这个维度。我们先分析这3个维度上有什么问题，再看DDD都能提供什么指导。
一、软件开发过程
一个简单系统的开发是不需要分这么多岗位的，大学期间做的一些兼职小项目就是一个人把需求，开发，测试，运维全做了，效率很高，如果说搞多个岗位多个人来做，反而效率很低。
不过这种情况随着项目复杂度上升就不一样了，一个人是没法搞定所有事情的，于是我们设立了各种岗位，通过团队分工让专业的人做专业的事情。
拿开发这个岗位来说还分了前端和后台开发，也是因为技术复杂性的要求，必须分工。一个理论是建立知识壁垒并能有效交换能提高效率，这个方面详细的论述可以看下八叉说的视频。通过专业分工来提升效率在生活中有很多地方都有体现，比如流水线作业什么的，这在国富论和科学管理中也有提到，这个方面详细的论述可以看下八叉说的视频。
