阅读目录：
- 1.背景
- 2.从业务开始
- 3.从战略到战术
- 4.借助外力推动研发（QA、领导、自动化测试）
- 5.领域模型与SAAS平台的内核（价值最大化）
- 6.最后
1.背景
DDD本身的技术就不介绍了，本篇文章要分享下我在推广DDD或者说实施DDD的过程中的心得和宝贵的经验。事实证明，这是可行的方案。用好DDD是一回事，推广DDD是另外一回事。也许已经有一套客观理性的推广技术的方案，但是我只能说DDD非常特殊。
你可能觉得我在吹牛B，你们公司能实施DDD。实话告诉你，我们实施了DDD了，而且效果很明显，非常成功，有图有真相。我用一种方式让我们的最高领导人都一致赞成这个价值。如果你推广DDD的角度是从技术出发，那么我可以很肯定的告诉你行不通，在任何一家公司实施都不可能成功，除非老板是你爸。要想成功，你得让不懂技术的领导者能感觉到它的价值，解决了某个痛点，这样你就成功了一半。
在强调下，作为架构师，在我们的脑子里每天装的不是具体的一个技术，而是全局。你要把控的是一个面，是需要全面考虑。你可以自己回去研究某个技术，就比如我自己最近在学习JAVA、GO。技术人员每天都要学习的，懂得越多发现要学的东西越多，这是合理正常的。但是你要知道作为架构师的职责是什么，要搞清楚你本职工作的的目标是什么，这是我现在的良师益友给我最多的提醒和指导（借此真心的感谢我的领导）。
所以，我文章的标题里有价值导向，这符合企业运营规则，也符合我们人的思考方式。技术导向，是技术人员的思考习惯。这没错，但是如果我们要影响别人就要跳出来思考问题。
第一版是我亲手设计的，感觉还不错。
2.从业务开始
实施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等重要的技术概念。在此先打个小广告推广下。）