阅读目录：

• 1.背景

• 2.从业务开始

• 3.从战略到战术

• 4.借助外力推动研发（QA、领导、自动化测试）

• 5.领域模型与SAAS平台的内核（价值最大化）

• 6.最后

1.背景

DDD本身的技术就不介绍了，本篇文章要分享下我在推广DDD或者说实施DDD的过程中的心得和宝贵的经验。事实证明，这是可行的方案。用好DDD是一回事，推广DDD是另外一回事。也许已经有一套客观理性的推广技术的方案，但是我只能说DDD非常特殊。

我们都知道自己用好DDD问题不大，让一两个人用好DDD也问题不大。你也许代码控制能力很强，也或者你的组员对DDD都有兴趣，在你的领导下，你让他们编写DDD模式的代码，问题也不大。但是作为一名架构师我们的职责是要推广或引进适合本公司业务模式的某种技术或者最佳实践。你或许推广性能优化、界面设计等等，这都没问题。但是让你推广一些有着很强主观意识在里面的东西其实很难。因为每个人的思维模式不同，对问题的理解和抽象的方式也不同。那你如何让大家就DDD能达成一致的抽象理解呢。

你可能觉得我在吹牛B，你们公司能实施DDD。实话告诉你，我们实施了DDD了，而且效果很明显，非常成功，有图有真相。我用一种方式让我们的最高领导人都一致赞成这个价值。如果你推广DDD的角度是从技术出发，那么我可以很肯定的告诉你行不通，在任何一家公司实施都不可能成功，除非老板是你爸。要想成功，你得让不懂技术的领导者能感觉到它的价值，解决了某个痛点，这样你就成功了一半。

在强调下，作为架构师，在我们的脑子里每天装的不是具体的一个技术，而是全局。你要把控的是一个面，是需要全面考虑。你可以自己回去研究某个技术，就比如我自己最近在学习JAVA、GO。技术人员每天都要学习的，懂得越多发现要学的东西越多，这是合理正常的。但是你要知道作为架构师的职责是什么，要搞清楚你本职工作的的目标是什么，这是我现在的良师益友给我最多的提醒和指导（借此真心的感谢我的领导）。

所以，我文章的标题里有价值导向，这符合企业运营规则，也符合我们人的思考方式。技术导向，是技术人员的思考习惯。这没错，但是如果我们要影响别人就要跳出来思考问题。

第一版是我亲手设计的，感觉还不错。

2.从业务开始

实施DDD得有个前提，它是解决业务问题的，不是解决某个技术问题的。或者准确点讲，它是解决业务系统问题，不是解决非功能性技术问题的。这点要认识清楚。然后你要考虑你从哪个层面切入到整个研发流程中，让DDD的东西在某个环节发挥一定的作用，短期不要太急，不要一口气全部推广出去。这会让人觉得你是一个技术偏执人员，不是一个理性的架构师。切忌。

如何从业务开始就为其创造价值。这里有一个痛点就是业务术语、业务模型不统一，沟通成本太大。如果你能减少产品和技术的沟通成本，其实你就创造了价值，而且价值是巨大的。你可以引入DDD的知识来解决。有一个小窍门就是你刚开始不要提及什么DDD等一些专业的技术词汇，你要引导往这个方面去走。你可以说我们需要一个手册，里面包含了专业的业务术语解释，如果可以的话在包含点基本的业务结构。引导和合作的方式让产品整理出来，你在加以修改和整理，因为你是知道DDD的整个路径的。

这个时候其实你已经在实施DDD了，千万不要觉得DDD就是那些代码。

当业务手册逐渐成形，就会顺其自然的引导到技术人员那里。然后你在找个痛点将战术设计引入研发team中。还是那句话，不要太强调DDD的战术。从头到外如果你都不提DDD的概念让DDD落地才是最理想的。

慢慢的从OO的角度引入高内聚低耦合，然后通过DDD的战术帮助研发去理解。

3.从战略到战术

解决了业务问题，带来了价值。这是一个好的切入点，我们继续前行。慢慢开始引入DDD的战略概念，前提是你要得到大家的信任，要负责任。

引入战略设计模式，开始用专业的DDD战略术语进行交流和引导。当然如果你们的交流和讨论是敏捷的最好，借助白板快速达成一致。经过一段时间再通过现在正式的会议进行一个概念巩固。此阶段需要借助大量的分享和培训让这个氛围起来。先达成共识。

到目前为止我们已经全面开始DDD的推广，好几个研发部都看见了它的价值。好东西不要你多说，群众的眼睛是雪亮的。我们还实施了单元测试，这是何等的骄傲。核心的业务对象我们慢慢开始引入单元测试，手把手的教研发怎么写。

4. 借助外力推动研发（QA、领导、自动化测试）

有时候需要借助一些外力来帮助我们实施推广一些东西，这应该是通用的方式方法。那么DDD需要借助哪些力量来让推广更加的容易点。

可以借助QA来强调质量，比如引入codereview、同时把你的DDD包含在里面引入。要记住你的目标。

还可以借助你的领导来推广，当然有领导帮忙推广是幸福的，但是你要做好售前售后工作。别强推，适得其反。

还可以借助自动化测试的实施来推广你的领域模型提炼。通过单元测试让研发慢慢的重视领域模型的高内聚低耦合。

5.领域模型与SAAS平台的内核（价值最大化）

其实，到最后企业的SAAS平台创建首先需要的就是业务模型。你可以借助这个价值让DDD的价值最大化。而且事实也是确实如此。研究SAAS的人都了解，核心业务模型基本上是很少变化的。外围的个性化都是基于核心模型在扩展。

6.最后

其实仅凭一篇博文很难说清楚细节。我只是给热爱DDD的同志们分享点我自己的可行方案和心得。其实这里面还有很多宝贵的东西值得分享，我会在我的下本书中详细的分享出来。（《B2B电商平台系统架构设计》，一本讲解B2B业务模式的系统架构设计，里面将包含DDD、SOA、SAAS、GRASP等重要的技术概念。在此先打个小广告推广下。）

最后还想说一句，作为一名架构师要知道“价值导向”、“风险驱动”。要为企业创造价值，要为企业规避风险。你只要做好这两点就已经是相当的厉害了。要有耐性，要负责任，要做到良师益友，很多时候技术是要引导的，架构是在不断的演化中，所以不要急。目的是要做成，而不是我试过没成功。

 本文转自 王清培 51CTO博客，原文链接：http://blog.51cto.com/wangqingpei557/1719803，如需转载请自行联系原作者