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

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

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

SOA需求是另一回事。可重用服务还没有被识别。在我看来，有几个选择：

我想避免建造太复杂的东西。我经历过与业务代表、远程外观和DTO一起的项目，在这些项目中，每一次更改都需要修改几个层。然而，感觉好像这个SOA需求迫使我朝着那个方向前进。

更新：我想得越多，就越意识到设计远程API的必要性带来的复杂性。当然，这需要为服务创建接口，但是交换的实体呢？要么我走DTO的路，最终得到两个并行的对象层次结构(一个用于DTO，一个用于实际实体)，要么我走接口的路，为所有需要跨服务器传输的实体声明接口。不管怎样，这都会带来一系列新的问题，我们最终将编写大量的锅炉板代码。我以为我们已经经历了那个时代…

设计这个的最佳(或最差)方法是什么？

谢谢大家。

我将使用选项1，仔细标记创建业务层接口的服务，并且禁止从表示层调用此接口后面的任何内容。这使您能够在以后通过远程处理(无论您选择2号还是3号)切换到选项，成本相当低且可预测。

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

一个有趣的部分是，在划分表示时，还没有提到业务逻辑——这是当您必须基于表示层中存在的数据(例如用户和他/她的权限)来过滤来自业务逻辑的数据时。：)

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

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

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

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

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

WSo2SOA堆栈提供了各种适合您的体系结构的解决方案。请浏览http://wso2.org/了解相关信息。毕竟它是免费和开源的：)