DDD做为软件设计方法于2004年提出，一直不温不火，最近几年突然火起来了，为啥呢？正所谓机会给有准备的人，因为微服务的流行，大家都跃跃欲试把传统单体软件转成微服务架构，但理论很丰满，现实很骨感，光是分解微服务就让人找不到北，而DDD是歪打正着也好，富有远见也好，正好适合微服务转型设计，不火都难。
最近学习了领域驱动设计（Domain-Driven Design），感觉受益匪浅，那到底啥是DDD呢？这里分享一下学习心得。网上有很多详细的资料，感兴趣可以看看这个https://www.infoq.cn/article/implementation-road-of-domain-driven-design。
个人理解：DDD首先是一种设计思想，所谓思想就是回答“设计的本质是什么，主要逻辑是什么”这类大的问题。DDD强调要从业务视角思考怎么设计软件架构，设计一定要知道业务是什么样子的，业务的需求和问题是啥，有啥内在逻辑，而不是从软件技术技术本身出发，这个对设计而言就是大的方向问题。虽然这个方向说出来好像没什么，但是实践上很多软件人员更多是从软件本身开始设计，一遇到业务问题就绕道走，所以强调从业务出发是这个方法最有价值的地方，这种梳理就称为战略设计。
DDD不只回答了方向问题，也提供一套方法，软件设计是个高度逻辑化的工作，需要概念特别清晰，推导过程有章法可循。DDD提供了对业务描述的一套方法，先对业务实体进行抽象，定义了一些软件设计概念，如实体对象，值对象，聚合对象，服务等，也提供了对象关系之间的描述。这部分对业务人员来说理解起来不容易，但是一旦理解了，对业务理解也就更深入了。前面根据业务把战略设计好了，就可以利用这些软件概念把业务逻辑映射成软件架构，这种过程DDD称为战术设计。
DDD还是一种具体的实践指导，在实际工作中，组织跨部门讨论是很难的，软件兄弟抓业务人员讨论就更困难了，一是大家思维模式差异比较大，沟通自然比较困难；二是大家都忙，不一定好找人，而且找到了业务人员也没啥设计概念，当面讨论都难深入，别提电话邮件了效果就更差了。针对这两点，DDD首先干的一个事情就是把业务人员拉在一起，澄清概念，互相理解对方做的工作，这个方法DDD称为统一语言。其次DDD还开发了事件风暴方法，一步一步指导大家操作得出结论，为了有好的效果，操作指导具体到讨论时用什么颜色的标签纸。
对统一语言的重要性我觉得怎么强调都不过分，这个对业务设计太重要了。比如在故障定位的业务架构设计中，深入讨论后发现很多基本概念都是不统一的，例如TT故障单到底指什么？故障范围到底怎么定义，什么叫根因。如果这些都不明确，软件自然就不会有高质量。
但是事件风暴方法我倒是持半信半疑态度，半疑是因为这类操作方法和业务场景有关系，看起来方法适合短时间内收集业务需求，而我司业务人员和软件开发集成在一起，不一定这么死板操作。半信是因为目前讨论的确需要一个好的形式，说不定有效，当然实践上我觉得先分组输出再集成讨论也是一种选择。
另外说说翻译问题，大凡直译的文章都令人费解，例如中文PMBOK把项目翻译成一种临时性工作，怎么看怎么别扭。DDD 中Domain一词翻译成领域，直译没有问题，但不符合信达雅的原则，说起来很绕。DDD是从软件公司的通用软件架构师的视角来思考怎么设计软件的，对软件架构师而言，要给各行各业设计软件，这种情况最难的是啥，就是理解千差万别的行业领域，所以老外理所当然在方法中突出领域这两个字，不过按照中文习惯翻译成业务驱动设计会更好理解。还有Bounded Context翻译成限界上下文，本意是强调内部的事情内部解决，具体定义只在业务模块内有效。我更愿意把它翻译成组件，只是这个组件需要有明确边界和职责。
最后贴几页故障定位架构设计材料，大家感受一下实际的应用例子，按照高内聚低耦合的理念，TOP DOWN一步步分析业务，会很方便的导出软件架构。
作者：华为云专家 秦广溥