即使只是少量更改角度，也可能對您如何使用系統產生深遠影響。

假設您正在用Java編寫Web應用程序。 在系統中，您處理訂單，客戶和產品。 作為Web應用程序，您的類包括諸如Controller，PersonRepository，CustomerController和OrderService之類的訂書釘。 您如何將課程組織成包？

有兩種基本的方法來構建軟件包。 您可以專注于邏輯層，例如com.brodwall.myapp.controllers，com.brodwall.myapp.domain或com.brodwall.myapp.services.customer。 或者，您可以專注于域上下文，例如com.brodwall.myapp.customer，com.brodwall.myapp.orders和com.brodwall.myapp.products。 迄今為止，第一種方法最為普遍。 在我看來，它也是最沒有幫助的。

如果您圍繞領域概念而不是技術層來構建軟件包，則可以通過以下幾種方式改變思維：

首先，也是最根本的，您的思維模型現在將與系統用戶的思維模型保持一致。 如果要求您實現典型功能，那么現在很可能將重點放在系統軟件包的嚴格子集中。 例如，向表單添加新字段將至少影響相應域概念的表示邏輯，實體和持久層。 如果您的軟件包是圍繞層組織的，則此更改將影響整個系統。 一句話：圍繞功能而非技術組織的系統具有更高的一致性。 這個技術術語意味著一個類的大部分依賴項都位于該類附近。

其次，隨著軟件的發展，圍繞領域概念進行組織將為您提供更多選擇。 當一個程序包包含數十個類時，您可能需要將其拆分為幾個程序包。 討論本身可以啟發人。 “也許我們應該將客戶地址類別分離到com.brodwall.myapp.customer.address包中。 它似乎有自己的生活。” “是的，也許我們可以在需要地址的其他地方使用相同的類，例如供應商？” “很酷，那么com.brodwall.myapp.address呢？” 或者，也許您認為應該將訂單狀態代碼和付款狀態代碼放在“ com.brodwall.myapp.order.codes”包中。

另一方面，您有什么選擇拆分com.brodwall.myapp.controllers？ 您可以為客戶，訂單和產品創建子包，但是這些子包可能只具有一個或兩個類。

最后，也許是最有趣的是，使用領域概念進行包裝可以使您根據具體情況改變設計。 也許您確實需要一個OrderService來協調訂單的付款和運輸，而ProductController僅需要帶有存儲庫的基本create-retrieve-update-delete功能。 一個ProductService只會給您帶來麻煩。 如果com.brodwall.myapp.services包中缺少ProductService，這可能會造成混淆，或者至少會給您帶來麻煩的感覺，那就是出現了問題。 另一方面，如果com.brodwall.myapp.product程序包中沒有控制器，則沒關系。

而且，大多數系統都有一些不錯的零件，而有些則不太好。 如果您的服務包對您不起作用，那么您將無能為力。 但是，如果“產品”程序包爛了，您可以將其丟棄并重新實現它，而不會使整個系統陷入混亂狀態。

通過將實現某個功能所需的類彼此放在一起，并與實現其他功能所需的類分開，開發人員在開發一個功能時可以務實和創新，而不會負面影響其他功能。

不利的一面是，大多數開發人員對應用程序中的某些技術更滿意，而對其他技術則較不滿意。 圍繞功能而非技術進行組織會迫使每個開發人員考慮更多的技術挑戰。 有些程序員將其視為學習的動力，而其他程序員似乎寧愿不必學習新知識。

如果花我的錢來創建功能，我就知道我想要什么樣的開發人員。

細微的變化會產生很大的影響。 通過圍繞功能組織軟件，您將獲得一個更加一致的系統，可以進行擴展。 它可能會給您的開發人員帶來挑戰，但會降低實現功能所需的交接數量，并會挑戰開發人員以改善他們正在處理的應用程序部分。

參考： Java 合伙人 Johannes Brodwall在“ 更大的盒子里的思考”博客中的更改Java包名稱如何改變了我的系統架構 。