领域/驱动设计对软件复杂度的应对

不管是因为规模与结构制造的理解力障碍，还是因为变化带来的预测能力问题，最终的决定因素还是因为需求。Eric Evans认为“很多应用程序最主要的复杂性并不在技术上，而是来自领域本身、用户的活动或业务”。因而，领域驱动设计关注的焦点在于领域和领域逻辑，因为软件系统的本质其实是给客户(用户)提供具有业务价值的领域功能。

一、需求引起的软件复杂度

需求分为业务需求与质量属性需求，因而需求引起的复杂度可以分为两个方面：技术复杂度与业务复杂度。

技术复杂度来自需求的质量属性，诸如安全、高性能、高并发、高可用性等需求，为软件设计带来了极大的挑战。让人难受的是这些因素彼此之间又可能互相矛盾互相影响。例如，系统安全性要求对访问进行控制，无论是增加防火墙，还是对传递的消息进行加密，又或者对访问请求进行认证和授权，都需要为整个系统架构添加额外的间接层。这不可避免会对访问的低延迟产生影响，拖慢了系统的整体性能。又例如为了满足系统的高并发访问，我们需要对应用服务进行物理分解，通过横向增加更多的机器来分散访问负载;同时，我们还可以将一个同步的访问请求拆分为多级步骤的异步请求，再通过引入消息中间件对这些请求进行整合和分散处理。这种分离一方面增加了系统架构的复杂性，另一方面也因为引入了更多的资源，使得系统的高可用面临挑战，并增加了维护数据一致性的难度。

业务复杂度对应了客户的业务需求，因而这种复杂度往往会随着需求规模的增大而增加。由于需求不可能做到完全独立，一旦规模扩大到一定程度，不仅产生了功能数量的增加，还会因为功能互相之间的依赖与影响使得这种复杂度产生叠加，进而影响到整个系统的质量属性，例如系统的可维护性与可扩展性。在考虑系统的业务需求时，还会因为沟通不畅、客户需求不清晰等多种局外因素带来需求的变更和修改。如果不能很好地控制这种变更，就可能因为多次修改导致业务逻辑纠缠不清，系统可能开始慢慢腐烂，变得不可维护，最终形成一种如Brian Foote和Joseph Yoder所说的“大泥球”系统。

以电商系统的促销规则为例。针对不同类型的顾客与产品，商家会提供不同的促销力度;促销的形式多种多样，包括赠送积分、红包、优惠券、礼品;促销的周期需要支持定制，既可以是特定的日期，例如双十一促销，也可以是节假日的固定促销模式。如果我们在设计时没有充分考虑促销规则的复杂度，并处理好促销规则与商品、顾客、卖家与支付乃至于物流、仓储之间的关系，开发过程就会变得踉踉跄跄，举步维艰。

技术复杂度与业务复杂度并非完全独立，二者混合在一起产生的化合作用更让系统的复杂度变得不可预期，难以掌控。同时，技术的变化维度与业务的变化维度并不相同，产生变化的原因也不一致，倘若未能很好地界定二者之间的关系，系统架构缺乏清晰边界，会变得难以梳理。复杂度一旦增加，团队规模也将随之扩大，再揉以严峻的交付周期、人员流动等诸多因素，就好似将各种不稳定的易燃易爆气体混合在一个不可逃逸的密闭容器中一般，随时都可能爆炸：

随着业务需求的增加与变化，以及对质量属性的高标准要求，自然也引起了软件系统规模的增大与结构的繁杂，至于变化，则是软件开发绕不开的话题。因此，当我们面对一个相对复杂的软件系统时，通常面临的问题在于：

问题域过于庞大而复杂，使得从问题域中寻求解决方案的挑战增加。该问题与软件系统的规模有关。

开发人员将业务逻辑的复杂度与技术实现的复杂度混淆在一起。该问题与软件系统的结构有关。

随着需求的增长和变化，无法控制业务复杂度和技术复杂度。该问题与软件系统的变化有关。

针对这三个问题，领域驱动设计都给出了自己的应对措施。

二、领域驱动设计的应对措施

1. 隔离业务复杂度与技术复杂度

要避免业务逻辑的复杂度与技术实现的复杂度混淆在一起，首要任务就是确定业务逻辑与技术实现的边界，从而隔离各自的复杂度。这种隔离也是题中应有之义，毕竟技术与业务的关注点完全不同。例如在电商的领域逻辑中，订单业务关注的业务规则包括验证订单有效性，计算订单总额，提交和审核订单的流程等;技术关注点则从实现层面保障这些业务能够正确地完成，包括确保分布式系统之间的数据一致性，确保服务之间通信的正确性等。