开发出一款基于业务的高质量软件产品，一直是架构师与软件开发工程师为之努力的目标，之所以说是努力的目标，是因为这其中存在众多的难题。

比如：如何将业务需求准确的转化为软件设计?如何能让团队人员在开发时能专注于业务，而不是技术本身?如何解决跨部门间语言沟通问题，如开发与业务之间的沟通障碍?如何解决软件系统不会随着时间推移而慢慢腐烂的问题等等……

为了解决这一系列的问题，15年前，Eric Evans提出了一个行之有效的方法论，即领域驱动设计(Domain Driven Design，简称DDD)，Eric Evans也因此享誉全球的IT圈。

略微让人遗憾的是，对于DDD，国内了解的人却并不多，我们也甚少听闻，业界有宣称应用了DDD原则的项目和软件。

没有掌握DDD的人，抱怨这一技术过于晦涩、在现实中根本无处着手。而掌握了它的人却觉得没那么难，不过是一种很自然的设计方法选择。

DDD对架构师和软件开发工程师意味着什么?对企业又意味着什么?我们应该如何正确的理解DDD并落地使用它?DDD高手是如何养成的?

近日，由ThoughtWorks发起的第二届领域驱动设计中国峰会(2018 DDD China Conference)在北京召开，笔者有幸采访到2位DDD的实践型专家，他们分别是民航信息技术总监，领域驱动设计中国峰会话题出品⼈张逸，ThoughtWorks高级咨询师，周宇刚。一起来看他们的经验之谈。

如何学习并使用DDD?

对于98年大学毕业的张逸来说，2006年的他，已经是一名有着丰富编程经验的老程序员了，就在那年，他通过Eric Evans的《领域驱动设计》一书，第一次接触到DDD。

“那个时候，学习DDD主要靠看书，外加自己琢磨，因为，没有人教，也没有氛围。”张逸说。

与此同时，他也开始在工作中逐渐尝试使用DDD，因为Eric一书晦涩难懂，并不好理解，因此，在实践的过程中，很多时候他都是一知半解的在做，就这样持续不断的实践了10多年。

“类似航延结算、协同决策等偏业务的系统，我们就会尝试采用DDD去改进系统架构，改进代码质量，但过程并不是那么顺利，走的磕磕绊绊的。有时间周期问题，还有团队成员能力问题。” 张逸说。

如今回过头来再看，一个项目，纯粹按DDD的方式去做的比较少，很多项目因为历史遗留问题，再加上团队在DDD理解上的一些分歧，导致很难有项目完全按照DDD去做，但会引入一些DDD思想。当找不到答案时，其实还是从设计的本质去看，甭管是否符合Eric Evans书中所介绍的东西。

周宇刚接触DDD的时间是 2009，比张逸略晚，很难想象他是一个做过导游的程序员，周宇刚学习DDD的原因是在日常编程工作中遇到很多挑战，比如，一个预订流程，面向对象应该如何去做?对象是什么?怎么协作?

直到有一次，无意中看到了Eric的书，仅看到战术设计的前半部分，就让他如获至宝。为了进一步学习DDD，他还特意去国外网站Stack Overflow上注册了个账号，就是为了去看看别人是如何学的。其实，跑到国外网站去看也是无奈之举，因为搜遍了国内网站，发现根本没人在聊DDD。

事实上，书的后半部分战略设计甚至还没来得及看，他就已经等不及了，要在自己项目中去实践。

作为Team Leader，他工作中有较大的自主权，所以，比较容易的就在自己项目中开始尝试，但过程是曲折的。“因为最初并不知道DDD到底是什么?一边要尝试去理解它，一边又要在自己项目中去实践”，周宇刚说。

当书上的知识或别人的案例跟实际项目不是特别契合时，在实践的过程中应该怎么去积累自己的经验呢?周宇刚认为，要跳出这个领域去设计，因为，我们追求的不是用不用DDD，而是用了DDD能达到什么效果。

如何正确理解DDD?

为什么很多人会觉得DDD很难学?因为，它就是一个思想，一个方法。周宇刚说。

开始，你以为DDD是一个面向对象的建模方法，能告诉你企业应用架构该怎么做，慢慢的，你又会发现，它告诉你的是怎么识别问题，如企业应用中的问题，业务领域的问题，哪些应该拆开处理……

事实上，DDD最初是一个综合软件系统分析和设计的面向对象建模方法，如今已经发展为一种针对大型复杂系统的领域建模与分析方法。

张逸认为，要了解DDD，首先得弄清楚它的历史背景与来龙去脉。

虽然，从Eric Evans出版那本划时代的著作《领域驱动设计》至今，已有差不多十五年时间,DDD也发生了一些变化，但Eric Evans为什么要提出DDD?这是学习DDD需要去了解的。

2004年，Eric Evans提出DDD，刚好是面向对象设计大为流行之时，UML也是甚嚣尘上，但是，这个时间节点上，软件设计还有一个致命的问题，软件系统开发还是从数据库角度去进行。当然，这里面涉及多种原因的，也是需要了解的。

原因一、当时的软件系统开发，并没有现在的多样性，系统操作的源头还是操作数据库，只是简单与复杂的区别。

原因二、软件行业本身很像是一个软件作坊，依靠的是老代新的传承方式。而老人最早接触到的就是面向数据库的设计，所以，虽然已经有面向对象，但开发者的开发工作仍然是基于数据库驱动。

因此，Eric Evans的书中就特别强调，如果采用面向数据库设计的思维去建模，很难去享受DDD带来的好处。张逸认为，要正确理解DDD的最关键的一点，是理解Domain Driven，并由此角度去驱动它，而这需要保证两点：

一、在设计时，压根就不要去考虑技术实现，只考虑业务，只考虑domain。

二、DDD不纯粹是一个软件开发方法，强调Domain，强调领域就要有沟通，一定要有协作，很多人之所以做DDD比较困难，甚至于做的不好，就是没有业务人员参与，基于业务的沟通机制是DDD最核心的。

DDD对企业、对架构师和软件开发工程师意味着什么?

在周宇刚和张逸看来，DDD对企业有2个方面的价值，一是能帮助企业识别自身核心领域，决定企业资源的运用。二是能帮助企业优化团队组织结构与文化。

周宇刚说，从价值导向看，DDD对于企业而言，是一种策略，能帮助企业识别自身核心领域，决定了企业资源怎样去运用，来支撑核心竞争力。比如核心领域，需要花大精力去做，非核心领域，可以采用更简单、更快速的方式去做，甚至直接采购成熟的软件套件。

而张逸则就DDD对团队组织结构和文化的价值进行了阐述，他表示，很多时候并不是技术上的问题，而是团队组织结构和文化方面的问题。当然这不纯粹是DDD能推动的，还可以通过敏捷或者精益的方式。

对架构师而言，DDD对架构师落地战略设计是会有帮助的，周宇刚说。因为，DDD解决跨部门间语言沟通问题，在业务、产品、开发之间建立领域通用语言以提高沟通效率。而对于开发者，DDD的作用更实际，能帮助开发者正确地开发所负责项目的代码。

张逸认为，对架构师而言，DDD能帮助架构师确认系统、领域边界，边界确认好，即使里边有问题，只要边界是稳定的，那么，系统就不会受到太大影响。

边界控制好，整体架构就会很清晰，把控也会更直观，这样的架构就不容易腐烂，现在的软件系统最大的问题，是随着时间推移它就会慢慢腐烂。而且把边界控制好，代码落到实现层面上也就相对容易。

对于开发者，张逸认为DDD主要有两个层面价值：

一、能够帮助开发者补充知识，不想当架构师的开发者不是一个好的开发者，开发者不能只满足于架构师分配的一亩三分地，也必须了解DDD知识。开发者如果只知道架构师要干嘛，却不知道架构师为什么要这么干，是很难提高的，这也不利于开发者去实现出来。

二、一体化的知识结构，从DDD落地上说，因为DDD更偏向于业务，更希望从业务的角度去看，所以，DDD能更好地和开发者所掌握的一些最基本设计原则匹配起来。