我在《解构领域驱动设计》一书中分析了软件复杂度的成因，一曰规模，一曰结构，还有一个则是变化的影响。规模与结构存在一定的矛盾关系：解决规模复杂度的有效方法为“分而治之”，一旦系统被分解为多个更为细小的软件元素，结构复杂度就会增加。结构与变化之间存在互相影响的关系：如果结构控制不合理，变化带来的影响就会更强，使得系统更加复杂。
认真分析结构和变化对系统复杂度的影响，一个关键是对依赖的控制。当我们对系统进行分解时，依赖会成为我们无法绕开的问题，它是技术债的重要组成部分，是不可避免的。如果没有控制好依赖，系统的架构就会随着时间的推移不可避免地腐化下去，如人不可避免的老去。
要合理控制依赖，只有两个可行的思路：
购买《解构领域驱动设计》，请扫描上图二维码在京东购买。
软件的核心是其为用户解决领域相关的问题的能力。 所有其他特性，不管有多么重要，都要服务于这个基本目的。
——Eric Evans，《领域驱动设计》
应对复杂度的挑战，或许是构建软件的过程中唯一亘古不变的主题。为了更好地应对软件复杂度，许多顶尖的软件设计人员与开发人员纷纷结合实践提出自己的真知灼见，既包括编程思想、设计原则、模式语言、过程方法和管理理论，又包括对编程利器自身的打磨。毫无疑问，通过这些真知灼见，软件领域的先行者已经改变或正在改变我们构建软件的方法、过程和目标，我们欣喜地看到了软件的构建正在向着好的方向改变。然而，整个客观世界的所有现象都存在诸如黑与白、阴与阳、亮与暗的相对性，任何技术的发展都不是单向的。随着技术日新月异向前发展，软件系统的复杂度也日益增长。中国有一句古谚：“道高一尺，魔高一丈。”又有谚语：“魔高一尺，道高一丈。”究竟是道高还是魔高，就看你是站在“道”的一方，还是“魔”的一方。
在构建软件的场景中，软件复杂度显然就是“魔”，控制软件复杂度的方法则是“道”。在软件构建领域，“道”虽非虚无缥缈的玄幻叙述，却也不是绑定在具象之上的具体手段。软件复杂度的应对之道提供了一些基本法则，这些基本法则可以说放之四海而皆准，其中一条基本法则就是：能够控制软件复杂度的，只能是设计（指广泛意义上的设计）方法。因为我们无法改变客观存在的问题空间（参见2.1.2节对问题空间和解空间的阐释），却可以改变设计的质量，让好的设计为控制复杂度创造更多的机会。如果我们将软件系统限制在业务软件系统之上，又可得到另外一条基本法则：“要想克服”（业务系统的）复杂度，就需要非常严格地使用领域逻辑设计方法。在近20年的时间内，一种有效的领域逻辑设计方法就是Eric Evans提出的领域驱动设计（domain-driven design）。
计算机编程的本质就是控制复杂度。
——Brian Kernighan
复杂的事物中蕴含着无穷的变化，让人既沉迷其美，又深恐自己无法掌控。我们每日每时对软件的构建就在与复杂的斗争中不断前行。软件系统的复杂度让我觉得设计有趣，因为每次发现不同的问题，都会有一种让人耳目一新的滋味油然而生，仿佛开启了新的旅程，看到了不同的风景。同时，软件系统的复杂度又让我觉得设计无趣，因为要探索的空间实在太辽阔，一旦视野被风景所惑，就会迷失前进的方向，感到复杂难以掌控，从而失去构建高质量系统的信心。
那么，什么是复杂系统？
在《解构领域驱动设计》书中的领域建模阶段，我提出了以业务服务为核心进行设计与建模的方法——服务驱动设计。通过该方法可以在静态的领域设计模型基础之上，以业务服务规约为基础，通过分析需求，对业务服务进行任务分解，获得以子任务构成的任务树。这棵树以业务服务为根，组合任务为枝，原子任务为叶，既体现了业务服务的执行过程，又进行了适度的封装，建立了一定的封装层次。
一旦获得了子任务树，即可对树中的每一个子任务进行职责分配，根据其特点分别分配给远程服务、本地服务、领域服务、聚合、端口。它们是构成限界上下文的主要对象角色，我将其称之为“角色构造型”，可以和我提出的菱形对称架构结合：
