我正在開發將不同接口連接到不同系統的Java EE應用程序。具有與其他系統不同接口的Java EE應用程序的哪些部署
我：
然後我有一些所謂的叫業務邏輯背後的數據庫操作和調用一些後端系統。
你將如何分割在不同的部署本企業應用？我看到三種不同的方式：
我會傾向於第一溶液的第四模塊，包一切一起在一個部署，錯誤修正和發佈wi將主要影響多於一個模塊。但是也有一些缺點嗎？
在書可以讀了很多關於JEE但很少了解這些類型的最佳實踐。
位很難說哪一個是最好，但這裏是我的2美分的價值。
所以，你可以有一個單一的大耳的最大缺點是，你必須重新部署世界作出一個小的變化。所以就基於此，我不會爲了一個大耳朵而去。想象一下，EAR是100MB大的還是荒謬的。
此外，由於一切都在一隻耳朵，如果你需要一個模塊，服務，豆或任何移動到另一臺服務器規模，你將不得不作出的EAR一些根本性的變化給它分開。這將招致的開發時間和成本再次
摘要：
你簡而言之第一種方法是一種簡單的部署沒有重大。但請記住，您必須重新部署所有內容。在一個非常大的應用程序中，這將會成爲一個問題。最大的麻煩將擴展應用程序拆分將花費時間，精力和金錢。
你的第二個選項是一個小更模塊化。然而，這些組件似乎有一些業務邏輯共享。因此，對一個EAR的更新可能意味着對其他EAR的級聯更新。這基本上是重複的工作。
摘要：
部署更加模塊化，使您在部署選項中具有更多的靈活性。但是部署更復雜。由於業務邏輯和可能的數據訪問邏輯不在共享模塊中，因此代碼在幾個地方被複制。這種重複會導致更高的測試和開發成本。
您的第三個選項分離了跨域的問題。在這種情況下，客戶域，網站域，移動域和業務邏輯域。雖然這需要努力部署，但您有更多的選擇。
總結：
由於共享邏輯被放置在單獨的模塊，這將導致一個更容易維護的設計。您的業務邏輯中的單元測試也將具有高質量，因爲它們現在不會綁定到特定的接口/域。因此測試會更容易，質量保證會更高。您還可以消除重複工作。
這個設計也比較容易擴展。將不同的EARS移動到不同的服務器上或擴展服務器。一個缺點是部署要複雜得多。
感謝您的回答，所以我明白，每種解決方案都有其自身的優點/缺點。 – boskop