构建前瞻性应用架构的优秀实践

为什么应用架构如此重要/strong>

通常，应用架构包含了所有的软件模块、组件、内/外部系统、以及构成应用之间的交互关系。显然，结构良好的应用架构，可以确保您的应用能够根据业务和用户的需求进行预期的扩展。同时，好的架构既能够合理地隔离不同的功能概念，又可以在内/外部形成良好的依赖关系。

相反，如下图所示，如果您在针对各种需求的初期设计时，以及后期的变更中，忽略了对于应用架构的合理构建与维护，那么将会导致不同组件之间，依赖关系的错综复杂，甚至难以同步与管理。

架构画布的逻辑组成如上图所示。其中，从下往上分别是：

· 基础层：在该层中，您可以实现所有可重用的非功能性需求。例如：连接到外部系统，或者使用可重用的UI模式与主题库，来扩展现有的框架服务。

· 核心层：在该层中，您可以实现各种核心的业务服务。例如：各种围绕着业务概念的服务、业务规则、业务实体、业务交易和业务部件等。您需要让这些服务独立于目标系统，并根据基础服务来抽象出任何可能的整合信息。可见，通过基础层和核心层，您已经隔离出了所有可重用的服务或组件。

· 最终用户层：在该层中，您可以通过使用基础与核心层的服务，来支持用户界面，以及与用户交互的流程。值得注意的是：为了确保整个生命周期的独立性，处于该层面上的模块，不应为其他模块提供服务。

架构的验证

为确保设计架构的合理性，且不会产生“意面式”的烂尾，下面我将为您提供一些可以遵循的准则和建议。

1.不要带有横跨三个层面的向上引用

鉴于前文提到的结构化分层，我们显然不应该让与业务无关的基础服务，去依赖核心业务;也不应该让可重用的服务，依赖各种最终用户的接口。此外，向上引用往往会产生一个群集。如下图所示，在该群集中，存在直接或间接链接关系的任何两个模块，都具有循环依赖性。

也就是说，如果最终EU1调用到了EU2，则表明EU1无法独立于EU2，同时他也就不能独立于EU2下面的层级结构中的集群。

3.避免在核心模块和基础模块之间进行循环引用

如果您能够遵循前面提到的两个规则，那么就不必担心最终用户模块之间可能出现循环引用。反而，我们应当重点避免在核心模块和基础模块之间，可能出现的循环引用。此类模块之间的循环引用主要产生于：一些业务概念没能被正确地抽象，进而对代码的管理产生不良的影响。

下面是一组能够确保设计出前瞻架构的参考规则：

规则1：从模块的架构画布准则开始

我们应按照上面给出的建议，对模块进行正确地分层。

规则2：隔离公共服务

将各个模块正确地放置到位后，我们就可以开始设计应用了。如前所述，如果在“最终用户应用2”上有一个模块会使用到“最终用户应用1”上某一个模块，那么我们就应该对通用核心应用进行隔离，以免产生依赖性。如下图所示，如果两个应用要进行内容上的共享与交互，则需要在彼此隔离的情况下，通过通用的应用服务来实现。

规则4：分清参与者角色

与所有者角色类似，参与者也有各自不同的节奏。例如：有一个提供不同保险业务的门户 站。其所有业务线都处于同一个应用中，那么任何一个业务(例如车险业务)的任何更改都不可能独立于其他业务。因此，实际上是由那个最慢的业务线，决定了整体应用的发布周期。

如下图所示，我们需要通过在每条业务线中创建单独的应用，让每个参与者都可以预估自己的交付速度。在此基础上，我们可以根据项目的具体需求，或是将不同参与者的任务相互隔离，或是通过内容共享的方式，加强他们的协作。

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树使用JDBC操作数据库数据库操作91648 人正在系统学习中