多层web应用架构_多层架构（3）–应用层

多层web应用架构

介绍

由于业务文档被认为是域层的输入，因此系统 需求规范是应用层的主要输入文档。 该层的范围是提供对系统定义要求的实现。 因此，很容易理解，其中包含的大多数逻辑都是面向过程的，因此链接到特定的系统实现。

什么是业务流程？

在一般情况下， 业务流程 （或简称为Process ）可以看作是几个任务的组合，按照一定的流程组合在一起就可以实现自动化特定功能需求的目标。 流程通常映射到特定需求，因此它没有很大的机会被其他流程重用 （父流程由几个较小的流程组成时除外），但是单个任务可能会有。 一个流程可以组成哪些不同类型的任务？ 我们可以考虑确定3种主要类型：业务任务，实用程序任务和应用程序任务。

业务任务

如先前的“域层 ”一文中所讨论的， 业务任务被视为不可知 逻辑 ，属于设计域 业务模型的一部分。 举一个清晰的例子，与工厂或存储库或验证规则相关的所有逻辑均被视为业务任务。 为了进行更深入的分析，工厂内部将拥有一种逻辑，该逻辑允许在状态立即被视为经过业务验证的状态下创建业务实体。 该代码肯定会在多个过程中使用，例如，必须一次创建多个实体。

实用程序任务

效用任务是不可知逻辑的最佳示例，因为它自然地与任何特定过程或实体都不相关，因为它仅提供有价值且可重用的逻辑。 实用程序任务的示例可以是给定两个点返回它们的距离的任务，或者给定文本返回遵循特定格式条件的格式化文本的任务。 该代码的位置取决于其用途：如果它与某些域实体相关，则可能在域层中，或者如果与任何域实体不相关，则可能在应用程序层中。 有时，当在企业范围内的环境中工作时，具有仅包含实用程序任务的另一层以允许在不同应用程序之间重用和共享也可能很有趣。 例如，在SOA中 ，通常将一个标记为“ 实用程序服务”的服务类别驻留在单独的层中。

应用任务

应用程序任务完成了系统要求中的逻辑的实现，但该逻辑不是域业务模型的一部分。 我通常会尝试应用此定义，即使在业务文档和系统文档没有很好地分开时（尤其是在最常见的情况下……），有时也不总是很明确。 描述应用程序任务的另一种方法是扩展业务和实用程序Taks提供的功能的逻辑。

过程逻辑

最终， 过程逻辑被认为是在预设计的逻辑流程中简单地构成多个任务 ，处理异常和管理事务的所有逻辑。 因此，流程通常不实现任何纯逻辑，而只是将现有逻辑组合成新的配置。 这就是为什么我们也可以将其归类为控制器。 流程被视为与系统进行每次交互的入口点。 用于SOA的WS-BPEL是用于流程定义的语言的示例。 对于桌面应用程序 ，流程是UI操作将直接调用的过程。

应用服务

由于应用层应该对基础设施的实现保持不可知论 ，因此需要委派基础设施层来实现在应用层中定义的应用逻辑。 对于域层 ，只需简单地定义逻辑接口，然后使用接口实现分离的概念（如多层体系结构中所述 ）来调用逻辑的实际可用实现，就可以轻松完成此操作。 下图显示了应用程序层可能包含的最终图片。

结论

应用层包含在大多数情况下特定于系统实现的逻辑。 无论如何，为了提高可重用性 ，它总是可以分成小的水平层 ，这些层可以被重用并集成到不同的应用程序中。 与用户界面和基础架构相关的技术仍应远离此层。

参考： 多层体系结构（3）–我们的JCG合作伙伴 Marco Di Stefano在“ 重构思想”博客上的应用层 。

翻译自: https://www.javacodegeeks.com/2013/05/multilayered-architecture-3-the-application-layer.html

多层web应用架构