4月，InfoQ 发布了软件架构与设计的趋势报告。在报告中可以看出，微服务、领域驱动设计等已经非常流行，并成为目前软件开发行业的主流趋势。
大家都知道，微服务划分的一个重要理论基础就是领域驱动设计。但由于 DDD 门槛高、概念多，体系庞大又抽象，再加上缺少实践经验和案例指导，很多开发人员对 DDD 存在不少疑惑：
理论文章多，涉及太多知识点，无从下手！
这么牛逼的技术，不能落地有什么用？
为何需要领域专家参与到项目开发中来？
DDD 与微服务的关系？
DDD 落地案例市面上少见，真的靠谱吗？
领导都不懂 DDD，怎么推！
……
许多朋友对其价值收益感受不明显，主要这两点原因：一是落地困难，对开发人员的能力要求比较高，二是不清楚到底用在哪里，为什么要用、怎么用。
其实，DDD是一套完整而系统的设计方法，并非一种架构。它能带给你从战略设计到战术设计的标准设计过程，使得你的设计思路能够更加清晰，设计过程更加规范，有助于提高技术人的架构设计能力。无论是在新项目中设计微服务，还是将系统从单体架构演进到微服务，DDD 都大有助力。
从Eric Evans的《领域驱动设计：软件核心复杂性应对之道》一书的书名就可以看出这一方法论是为了解决软件核心复杂性的。也就是说软件业务越来越复杂了，领域驱动设计可以让事情变得简单。而实际情况是：领域驱动设计的门槛很高，没有很深厚的面向对象编码能力几乎不可能实践成功。
这一说法是否自相矛盾呢？Martin Fowler在PoEAA一书中给了一个有力的解释：我们把三层架构等除了领域驱动之外的架构方式都可以归纳为以数据为中心的架构方式，在图中是黑色的粗实线；领域驱动设计在图中是绿色的粗实线。- 当软件在开发初期，以数据驱动的架构方式非常容易上手，但是随着业务的增长和项目的推进，软件开发和维护难度急剧升高。
- 领域驱动设计则在项目初期就处在一个比较难以上手的位置，但是随着业务的增长和项目的推进，软件开发和维护难度平滑上升。
这幅图形象的解释了领域驱动设计和传统的软件架构模式两者在软件开发过程中解决复杂性之间的差异。
说到战略设计，我们要站在一个比较高的视角来看待这个问题，战略设计要解决的就是某个领域的问题，所以战略设计时，我们要构建好领域模型，保证我们的大方向是不会错的战略设计主要从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的限界上下文，限界上下文可以作为微服务设计的参考边界。战术设计则是要求我们从业务模型转向微服务落地 我们会将领域模型中的领域对象与代码模型中的代码对象建立映射关系，将业务架构和系统架构进行绑定。当我们去响应业务变化调整业务架构和领域模型时，系统架构也会同时发生调整，并同步建立新的映射关系。也有演进式架构的含义在里面。说到这里，大家可能对DDD有了一个粗略的，大体的认识，我们可以理解到，DDD能够帮助我们更好的在微服务的架构中进行合理的拆分，由于DDD要求我们建立标准的业务领域模型，所以DDD也能够很好地帮助我们设计企业的中台,DDD是一把利器，帮助我们解决架构中遇到的问题和挑战。
DDD是一套完整而系统的设计方法，并非一种架构。它能带给你从战略设计到战术设计的标准设计过程，使得你的设计思路能够更加清晰，设计过程更加规范，有助于提高技术人的架构设计能力。无论是在新项目中设计微服务，还是将系统从单体架构演进到微服务，DDD 都大有助力。
倘若能一直保持DDD的开放性，保持DDD的独立性，我觉得在未来的五年乃至十年，DDD仍将焕发生命力，只是它的面貌会更加多姿多彩，甚至超过Eric Evans对DDD的原初定义。毕竟，软件系统的核心只有两个：领域和算法。
