简单应用程序的复杂架构[关闭]

Question

作为一名顾问，我负责为外部公司设计应用程序的架构。此应用程序的要求相当简单，只需一个基本的 Web 应用程序、一两个传入 Web 服务和几个传出文档通道即可轻松解决整个问题。

由于两个非功能性需求，事情变得更加复杂：

1. 上述公司要求所有内部应用程序都必须通过企业门户提供（为了 UI、安全性和技术统一性）
2. 该公司要求所有应用程序都使用 SOA 原则构建，以便最终可以在 ESB 上发布服务并重用。

架构可以轻松适应门户要求。演示文稿将使用 portlet 构建并集成到门户主题中，并且将重用门户安全性。没什么大不了的。

SOA 需求是另一回事。可重用服务尚未确定。在我看来，有几个选择：

1. 业务逻辑部署在门户上并与表示层位于同一位置。没有服务公开，此决定被推迟。
2. 业务逻辑部署在单独的服务器上。设计了一个 API，所有服务都使用封闭协议（例如 RMI 或 Hessian）公开。对于最终需要重用的服务，可以在这些服务之上添加一个 SOAP API。
3. 业务逻辑部署在单独的服务器上。设计了一个 SOAP API，并使用此机制公开所有服务。

我想避免构建过于复杂的东西。我经历过业务代表、远程外观和 DTO 的项目，其中每一次更改都需要修改多个层。然而，感觉好像这个 SOA 要求强行将我推向了那个方向。

更新：我想得越多，我就越意识到设计远程 API 的需要会产生复杂性。当然这需要为服务创建接口，但是交换的实体呢？要么我采用 DTO 方式并最终得到两个并行对象层次结构（一个用于 DTO，一个用于实际实体），要么我采用接口方式并为需要跨服务器传输的所有实体声明接口。无论哪种方式，这都会带来一系列全新的问题，我们最终将编写大量样板代码。我以为我们已经度过了那个时代......

最好（或最差）的设计方法是什么？

谢谢大家。

Answer 1

我很高兴看到您在构建企业架构方面拥有一些实际经验并了解不同架构的后果。我见过很多顾问，他们刚刚读过一本关于一些新时尚技术的书……

选项 1 无疑是最实用且最实惠的。您将构建一个现在需要的应用程序，而不是投资于将来可能会或可能不会使用的服务。但我从您的描述中了解到，这可能很难卖给客户。

如果您必须使用分布式架构（选项 2 或 3），我仍然会尝试将尽可能多的内容放在门户服务器上。为此，业务逻辑这个术语必须以非常狭隘的方式定义。甚至与演示远程相关的所有内容（用户设置、用于演示的数据结构、已生成的报告等）都被声明为 演示逻辑，因此它可以在门户服务器上实现。因此，即使您无法避免远程处理带来的重复和复杂性，您也可以将其限制在更少的区域。 （根据手头的问题，您最终可能会在门户服务器上建立一个数据库，在业务逻辑服务器上建立一个数据库，因为它们之间有太多的数据引用，所以最好将它们合并为一个。希望情况并非如此在这里。）

根据我的经验，只考虑一个应用程序来编写可重用服务是一种浪费的投资。 servcie 接口对于这个单一应用程序将变得更加复杂，接口的一部分将永远不会被使用并且几乎不会经过测试（因为它是为一些想象中的未来应用程序而构建的）并且当第二个应用程序最终到达时，人们意识到它的要求与预见。因此需要重新设计服务并修改已经存在的应用程序。因此，除非您至少有两个（最好是三个）应用程序存在或正在实施，否则不要开始构建服务。它在金钱和服务接口的质量方面得到了回报。

此建议不是很具体，但您对应用程序业务需求的描述也是如此。由于您已签署保密协议，您可能无法提供更多信息。但我经常发现业务需求有助于支持或反对一个选项。例如。要求、相关数据、数据所有权和所涉及的过程可能比技术考虑更好地界定系统。

Answer 2

我会选择选项一，标记小心地创建业务层接口的服务并禁止从表示层调用此接口后面的任何内容。这使您可以稍后以相当低且可预测的成本切换到远程处理选项（无论您选择第二个还是第三个）。

如果这是不可能的，选项二承诺更有效地利用资源。

尚未提及划分表示和业务逻辑时的一个有趣部分 - 这是当您必须根据仅存在于表示层中的数据过滤来自业务逻辑的数据时，例如用户和他/她的许可。 :)