DDD专栏6：建模演练：如何使用DDD来设计支付风控系统？

​ 上一讲中，讲解了如何在软件架构的层面使用DDD来帮助我们设计出"高内聚、低耦合"的高质量软件，希望你能够对DDD的落地实践有个完整的蓝图，并能够在一些具体项目中大胆的进行实践，来完善DDD的其他细节。

​ 同时上一讲中也提到了，当应用进入微服务阶段，DDD将会体现出更大的作用。而对于微服务系统，最核心的难题其实是微服务的拆分。不合理的拆分方式不但不能提高研发效率，反而会加大系统的维护成本。因此，微服务的设计不是简单的应用拆分，而是对设计提出了更高的要求，需要更高效的"高内聚、低耦合"。而经过多年的实践，DDD领域驱动设计就是得到业界普遍认可的一种设计方案。但是，领域驱动设计应当要怎样推进呢？怎样从需求分析开始，到最后的程序落地，一步步设计出正确的微服务架构呢？这一讲我们将会以一个支付风控系统为例，来实际演练一下微服务的设计过程。

统一语言建模

​ 软件开发的第一个步骤也是风险最大的一个步骤就是需求分析。相信你在开发过程中肯定深有体会。在这个过程中，技术研发人员与业务人员似乎永远是站在对立面的，谁也说不清楚能让对方了解自己的需求或设计。业务方十分清楚他的业务领域知识，以及需要解决的业务痛点。但是，业务方不清楚技术要如何来解决业务痛点。他们只能根据他们的认知，想象产品要做成什么样子。所以这样的业务需求往往不太靠谱，难以实现同时也不太稳定。与此同时，在需求分析过程中，研发人员非常清楚技术细节以及能解决哪些业务问题，然而总是欠缺客户所在的业务领域知识，无法准确理解客户的业务痛点。

​ 关于如何统一技术方与业务方的认知，减少需求沟通过程中的信息丢失，业界有非常