我剛開始嘗試使用Spring Roo。它做了一個非常好的工作，幫助我們快速構建一個集成持久性的領域模型。由於它增加了持久性功能，我開始考慮以下問題：方面是否替代知識庫？
Roo在實際的類/實體中添加了查找器（從數據庫中加載符合變量標準的類的實例）。在DDD這是恕我直言的責任倉庫。存儲庫是設計中顯示的顯式類。當然，作爲一個方面，存儲庫功能隱藏在一個實體中，幾乎看不見。
所以這裏是一個問題：一個方面是一個真正的替代顯式存儲庫類嗎？ Roo AOP方法有什麼缺點？
從用戶的角度來看，將定位器添加到您的域類感覺更自然，但它會混合您的圖層。通過添加靜態查找器*（）save（），...方法，Grails使用相同的方法。
除了考慮它可能有實際缺點時不使用的web應用程序設置： 您的域類現在綁定到您的數據庫。如果您通過RMI或HttpInvoker將這些對象傳輸到富客戶端，則客戶端不能並且通常不會使用find *方法，因爲客戶端上沒有可用的會話/數據庫連接。
我一般喜歡允許域類引用服務層接口，以防止貧血域模型（http://martinfowler.com/bliki/AnemicDomainModel.html）。這有它自己的缺點，但至少提供了一個清晰的界限。在客戶端上，服務接口後面的具體實現可以將所有的方法調用代理到服務器（或者只是使用與remoting類似的synamic代理）。
因此，要回答你的問題：這可能是一個替代品，但你應該知道的可能的負面影響，使您的域類（即你的核心業務邏輯）系統之間的可移植性。
這取決於您的應用程序持久層的複雜程度以及您對它的控制程度。如果你的應用程序很簡單，可以通過JPA來實現，那麼這一切都可以通過Roo方面來處理。但是，如果您正在映射舊錶或需要高級數據庫內容，那麼您可能會發現自己處於這種情況下，只有出現這種情況，並且在這種情況下，存儲庫/數據模型可能仍然有用。
我認爲這是合乎邏輯的不一致（與層責任休息）進行混合兩種持久性模型，並以我的大部分應用程序需要這種先進的DB構建我的倉庫模型堅持嚴格。
我認爲將存儲庫方法添加到域對象是糟糕的設計。正確的地方是域類中的靜態方法。但是域對象和它們的管理是兩個不同的東西，應該分開。我更喜歡域對象和存儲庫。
我想動機是實現像Java一樣的Rails/Grails。