我正在开发一个 Java EE 应用程序，它用不同的接口链接不同的系统。
我有：
然后我有一些用于数据库操作和调用后端系统的业务逻辑。
您将如何将此企业应用程序拆分为不同的部署？我看到了三种不同的方式：
我倾向于第一个解决方案，将所有内容打包在一个部署中，因为错误修复和发布将主要影响一个以上的模块。但也有一些缺点吗？
在书籍中，您可以读到很多关于 JEE 的内容，但很少了解这类最佳实践。
【问题讨论】：
标签： jakarta-ee soap deployment architecture
很难说哪个最好，但这是我的 2 美分。
因此，单只大耳朵的最大缺点是，您必须重新部署整个世界才能做出微小的改变。因此，仅基于此，我就不会选择一只大耳朵。想象一下，EAR 有 100MB 大或类似的荒谬之处。
此外，由于一切都在一个 EAR 中，如果您需要将模块、服务、bean 或任何东西移动到另一台服务器以进行扩展，您将不得不对 EAR 进行一些根本性的更改以将其拆分。这将再次产生开发时间和成本
总结：
简而言之，您的第一种方法是简单的部署，没什么大不了的。但是请记住，您必须重新部署所有内容。在一个非常大的应用程序中，这将成为一个问题。最大的痛苦是拆分应用程序以进行扩展将花费时间、精力和金钱。
您的第二个选项更加模块化。然而，组件似乎有一些业务逻辑。因此，对一个 EAR 的更新可能意味着对另一个 EAR 的级联更新。这本质上是重复劳动。
总结：
部署更加模块化，让您的部署选项更加灵活。但是部署更复杂。由于业务逻辑和可能的数据访问逻辑不在共享模块中，因此代码在多个地方重复。这种重复会产生更高的测试和开发成本。
您的第三个选项跨域分离关注点。在这种情况下，客户域、网站域、移动域和业务逻辑域。虽然这需要努力部署，但您有更多选择。
总结：
由于共享逻辑被放置在一个单独的模块中，这将导致更易于维护的设计。您的业务逻辑中的单元测试也将具有高质量，因为它们现在不绑定到特定的接口/域。因此，测试会更容易，质量保证会更高。您还可以消除重复劳动。
这种设计也比较容易扩展。将不同的 EARS 移动到不同的服务器上和/或扩展服务器。一个缺点是部署要复杂得多。
【讨论】：