我正在开发一个Java EE应用程序，它将不同的系统与不同的接口相连接。
我有：
然后我为数据库操作和调用一些后端系统提供了一些业务逻辑。
您如何在不同的部署中拆分此企业应用程序？我看到了三种不同的方式：
我倾向于第一个解决方案，在一个部署中将所有内容打包在一起，因为错误修复和发布将主要影响一个模块。但是还有一些缺点吗？
在书中你可以阅读很多关于JEE但很少阅读这些最佳实践。
答案 0 :(得分：1)
很难说哪一个最好，但这是我的2美分。
因此，单一BIG耳朵可以带来的最大缺点是，你必须重新部署世界才能做出一点改变。所以，基于此，我不会去寻找一个大耳朵。想象一下，达到EAR大100MB或者像这样荒谬的东西。
此外，如果您需要将模块，服务，bean或任何内容移动到另一台服务器进行扩展，所有内容都在一个EAR中，您将不得不对EAR进行一些基本更改以将其拆分。这将导致开发时间和成本再次
要点：
简而言之，你的第一个方法是简单的部署没什么大不了的。但请记住，您必须重新部署所有内容。在一个非常大的应用程序中，这将成为一个问题。最大的痛苦拆分扩展应用程序将花费时间，精力和金钱。
您的第二个选择是更加模块化。但是，组件似乎共享了一些业务逻辑。因此，对一个EAR的更新可能意味着对其他EAR进行级联更新。这实质上是重复工作。
要点：
部署更加模块化，使您可以更灵活地部署选项。但是部署更复杂。由于业务逻辑和可能的数据访问逻辑不在共享模块中，因此代码在多个位置被复制。这种重复将导致更高的测试和开发成本。
您的第三个选项将跨域关注点分开。在这种情况下，客户域，网站域，移动域和业务逻辑域。虽然这需要部署工作，但您有更多选择。
要点：
由于共享逻辑放在一个单独的模块中，这将导致更易于维护的设计。您的业务逻辑中的单元测试也将具有高质量，因为它们现在不受特定接口/域的约束。因此，测试将更容易，质量保证将更高。您还可以消除重复工作。
这种设计也相对容易扩展。将不同的EARS移动到不同的服务器上，或者扩展服务器。一个缺点是部署要复杂得多。