Architecture 用于简单应用程序的复杂体系结构

作为一名顾问，我负责为外部公司设计应用程序的体系结构。这个应用程序的要求非常简单，整个问题可以通过一个基本的web应用程序、一两个传入的web服务和几个传出的文档通道轻松解决

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

该公司要求通过企业门户提供所有内部应用程序（用于用户界面、安全性和技术统一性）

该公司要求使用SOA原则构建所有应用程序，以便最终在ESB上发布并重用服务

体系结构可以很容易地适应门户需求。演示文稿将使用portlet构建并集成到门户主题中，门户安全性将被重用。没什么大不了的

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

业务逻辑部署在门户上，并与表示层位于同一位置。没有公开任何服务，此决定被推迟

业务逻辑部署在单独的服务器上。设计了一个API，并使用封闭协议（例如RMI或Hessian）公开所有服务。对于最终需要重用的服务，可以在这些服务之上添加SOAP API

业务逻辑部署在单独的服务器上。设计了一个soapapi，并使用该机制公开所有服务

我想避免构建太复杂的东西。我经历过与业务代表、远程facades和DTO合作的项目，在这些项目中，每一次更改都需要修改几个层。然而，这种SOA需求似乎将我推向了那个方向

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

设计这个的最佳（或最差）方法是什么

---

谢谢大家。

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

选择1当然是最务实和最实惠的。您应该构建一个现在就需要的应用程序，而不必投资于将来可能使用或不使用的服务。但据我从您的描述中了解，这可能很难销售给客户

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

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

---

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

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

如果不可能做到这一点，方案二将保证更有效地利用资源

划分表示层时一个有趣的部分是尚未提及业务逻辑-这是指您必须根据仅存在于表示层中的数据（例如用户及其权限）过滤来自业务逻辑的数据。：）