DDD实施经验分享—价值导向、从上往下进行（圈内第一个吃螃蟹DDD实施方案）

阅读目录：

2.从业务开始
3.从战略到战术
4.借助外力推动研发（QA、领导、自动化测试）
5.领域模型与SAAS平台的内核（价值最大化）

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的战术帮助研发去理解。