实战领域驱动设计开篇

软件的核心是为用户解决业务相关问题的能力，除此之外所有的其他功能，不管它有多么的花哨，都要服务于这个基本目的。然而，面对纷繁复杂的业务问题，我们如何才能开发出高内聚、低耦合，富有有生命力的软件呢？要达到这个目的，我们首先就要将目光聚焦于业务。

然而，这些年随着互联网的发展，我们在不停学习别人的轮子，乐此不疲，乐在其中，我们喜欢干这样的事情，因为它更技术。拿我自己的从业经历来说，2006 年左右，面对的需求大多是 WEB 开发，接触了好多流行的框架：Struts1、Webwork、Struts2、Appfuse、freemaker 模版引擎、早期的 Spring Framework、Hibernate 等等。为了解决搜索问题学习了 Lucene、solr、ES，工具类的轮子接触的就更多了：apache commons、google guava、Dom4j、xstream、jackson、gson、apache poi、ehcache、quartz 等等。2010 年左右，由于大数据开发需求增多，我又开始接触 hadoop、flume、sqoop、ooize、pig、kafka、storm、spark、flink 等等大数据相关的框架。这些框架大多都有一个很吸引人的宣传语“使用我吧，让你把精力更多的用于业务”。我们不否认框架的积极作用，但是，我们真正用于考虑业务的时间有多少呢？

另一方面，从公司的组织架构上看，直接和业务交流的是产品经理，技术开发人员的需求是由产品经理整理转述而来的，开一次产品需求讨论会就直接让开发确定开发排期了，开发对于业务的理解是基于产品经理的总结，属于二手信息。这种分工进一步导致开发远离业务，沉静在学习轮子的乐趣中。这种分工也导致开发和产品之间矛盾冲突，网上的段子满天飞，现实中还有大动干戈，互相切磋武艺的。难道产品和技术不应该是亲如兄弟的关系吗？他们的目的都是为了解决业务需求啊。这样的分工起初开发的进度还能保证，但是随着业务的深入，开发人员就不得不进行大的架构调整，或者是充当“救火队员”，冲在故障一线，陷入 BUG 泥潭。究其原因还是由于对业务了解的太少了，初期模型出了问题，产品和开发没有基于业务模型的通用语言，沟通上存在鸿沟。

2011 年 4 月底，iPhone4 开始在中国内陆发售。移动互联网的用户增多，流量猛增，传统的单体架构受到了挑战，分布式的微服务架构开始被人们提及，如何将业务拆分为一个个的微服务成为人们讨论的重点？这个时候人们又想起了 2003 年 Eric 在《领域驱动设计》一书中所阐述的方法，领域驱动设计又重新进入人们的视野。领域驱动设计鼓励开发人员向领域专家、产品经理学习业务相关的领域知识，将领域知识浓缩为领域模型，以领域模型为核心和领域专家、产品经理共同建立通用语言，跨过沟通的鸿沟。领域驱动设计从战略和战术两个层面给我们提供了设计指南。战略层面，用子域去分离问题，将问题化为我们脑力可以轻松驾御的子域，将核心力量和精力放在核心子域上，其次才是支撑子域和通用子域。用限界上下文（Bounded Contexr）来解决问题，在限界上下文内部建立以领域模型为核心的通用语言，消除概念上的歧义。通过上下文映射图来理清组织关系和上下游的系统关系，让开发对项目有全局认识。战术层面，在限界上下文内通过实体、值对象、领域服务、领域事件来建立模型，通过模块来组织，通过聚合、资源库、工厂来管理模型对象的生命周期。代码就是领域模型的直接映射，减少中间翻译。

前几年，业务中台的概念被人们提及，表明比特世界的触角伸向业务的纵深，业务复杂度进一步提升。在可预见的未来工业互联网、物联网、ToB 业务的需求会猛增，软件的长期趋势是软件会被应用于解决越来越复杂的问题，越来越深入这些业务的核心。面对越来越复杂的业务问题，开发人员应该以登高望远的姿态，“不畏浮云遮望眼”，坚持不懈的进行领域驱动设计的实践，掌握领域驱动设计的方法，它就是我们应对软件核心复杂性的法宝。

在开篇我们先给大家提供一张思维导图，让大家对领域驱动设计有一个总体印象：