本文建议前期做足够的架构设计，以便提供项目启动所需的结构，统一团队愿景以及评估可能的风险。

前期做完整设计的瀑布模型时代已经结束，但那是说开发人员应该在完全没有任何设计草图的情况下开始一个新的软件项目吗？如果没有进行充分的考虑就开始编写代码，却在数周后发现最初做的技术选择完全错误，那会发生什么？如果没有考虑设计原则和模式，系统设计成一个大泥球，那会发生什么？

另外，如果UML很大程度上被看作是开发人员编码路上的障碍，那是说团队不应该使用任何图形化的方式来一起交流他们想要构建的系统的设计？难道就没有一种方法既能创建刚好够用的前期设计，又不成为开发人员的负担，同时又能保证整个团队清楚如何按照计划取得项目的成功？有没有一种方法可以用来与所有团队成员交流设计，以保证他们正在构建同样的东西？

Simon Brown是一位来自欧洲的软件架构师和咨询师。最近，在布达佩斯Craft大会上，他在题为《敏捷与软件架构的本质》的演讲中试图解答这些问题，并就最小的初步设计和设计交流方式提供了建议。

演讲从“没有架构就不是解决方案”的假设开始，Brown建议做足够的前期设计，直到组件层。他基于他的C4模型将系统分成几层，如下图所示（该图片来自会议幻灯片-PDF）：

首先，需要考虑系统将如何使用以及它对其它系统有什么依赖。然后拟定容器。容器是一个可部署单元，如Web服务器、应用服务器、数据库、浏览器插件等等。这包括针对将要使用的技术做一些决策，因为系统实现不是“技术无关的”。接下来是容器内的组件。一个组件通常是一个高度相关的类的集合，它们一起实现了一项特定的系统功能。组件由模块或程序包来体现。Brown举了一个例子，其中就有这样一个出自其项目techtribesjed的组件，如下图所示：

图片的左侧是最初的组件，由两层构成，包括一个服务层和一个数据访问层，每层都有自己的程序包，但组件随后会整合进一个单独的程序包中，如图片右侧所示。在某些情况下，Dao接口以及分成两层和两个程序包是必要的，但在这种情况下，为了简单起见，Brown决定将两个合为一个。虽然本图给出了接口和类，但并不是说前期设计要详细到这种程度。只是决定组件本身，而不是它包含的类或者接口。

在设计好了系统的总体结构，并且到了组件层之后，前期设计过程还包含下图所示的两个阶段：

对于架构师而言，与整个团队分享他的愿景是很重要的，这样一来，他们都会构建同样的东西。图表很有用，可以使用工具画，也可以手工草绘。重要的是要有一个图形化的系统表述，包括它的结构、容器和组件，团队成员可以在接下来的任何时间查看这一表述。

另一个重要的阶段是评估系统构建过程中可能存在的风险。Brown建议使用风险风暴来识别这样的风险。整个团队分析架构模型，每个人都指出哪里可能有实现问题。对于该阶段，他建议包含概念验证或者一个系统原型。

最后一个建议与领导力相关。据Brown说，如果有一个领导者做系统架构，大多数团队都表现上佳，而如果系统足够大，更成熟的团队会使多人分担这一角色，以保证团队有上佳表现。