# DDD Chapter-6 Repositories ## 前言 此為Domain-Driven Design: Tackling Complexity in the Heart of Software (Eric Evans, 2003) 章節6 The Life Cycle of a Domain Object. 中關於Repositories的譯文，僅學習&學術交流用。 --- ## Repositories *To do anything with an object, you have to hold a reference to it. How do you get that reference?* 通常來說程式要與物件互動或是要做任何事之前，都需要取的這個物件的參照(reference)。 但要如何才能取得這個參照呢? *One way is to create the object, as the creation operation will return a reference to the new object.* 第一，通常在創造物件的過程中，物件自然會回傳一個代表新物件的參照。 *A second way is to traverse an association. You start with an object you already know and ask it for an associated object.* 第二，透過物件的關聯去遍歷(traverse)。 簡單來說，你可以從一個你已知的物件著手，透過它來檢索與它相關的所有物件去找到目標的參照。 *Any object-oriented program is going to do a lot of this, and these links give object models much of their expressive power.* 任何物件導向的程式(語言)都是在大量處理類似上述的事情， 這些關聯一定程度上賦予物件模型很大的表達能力。 *But you have to get that first object.* 但終究你還是必須找到那個初始的物件。 --- *I actually encountered a project once in which the team was attempting, in an enthusiastic embrace of MODEL-DRIVEN DESIGN, to do all object access by creation or traversal!* 我實際上碰到過一組富有熱情嘗試擁抱MDD(模型驅動設計)的設計團隊， 他們希望所有物件所的存取(獲取參照)都是遵守上述原則透過遍歷或是創建取得。 *Their objects resided in an object database, and they reasoned that existing conceptual relationships would provide all necessary associations. They needed only to analyze them enough, making their entire domain model cohesive.* 他們把所需的物件被儲存在一個物件資料庫(object database)內， 而他們認為以現存的概念關係(conceptual relationships)就可以滿足(需求)所有物件必需的關聯(associations)。 他們認為只需要分析足夠的充分，使他們的領域模型足夠內聚就可以達到上述目標。 *This self-imposed limitation forced them to create just the kind of endless tangle that we have been trying to avert over the last few chapters, with careful implementation of ENTITIES and application of AGGREGATES.* 但這些自行強加的限制迫使他們只能陷入某些無止盡的泥潭，內部存在的衝突大多都與實體的實作不夠全面以及程式的聚合(AGGREGATES)問題相關。 *The team members didn't stick with this strategy long, but they never replaced it with another coherent approach. They cobbled together ad hoc solutions and became less ambitious.* 最後，團隊成員並沒有長期堅持這種策略，但他們也從未用另一種連貫的方法取代它。 他們拼湊出了臨時解決的方式但團隊卻失去了最初的野心。 * 補充 AGGREGATES: Aggregate 是一種模式，簡單將程式碼切割成兩個步驟，首先定義一個 Entity做為聚合根(Aggregate Root)，第二部分是根據 Aggregate 的(完整性)規則對領域數據進行操作。詳細可以參照原文DDD的聚合。 --- *Few would even think of this approach, much less be tempted by it, because they store most of their objects in relational databases.* 很少有人會去細膩得思考上述的方法案例，更不用說被它所迷惑，原因是因他們將大部分這類物件存儲在關聯式資料庫中。 *This storage technology makes it natural to use the third way of getting a reference: Execute a query to find the object in a database based on its attributes, or find the constituents of an object and then reconstitute it.* 這樣的儲存技術自然而然的讓一開始我們提到的取得參照有了第三條路；據對象的屬性在資料庫中(執行查詢)查找對象，或找到對象的組成部分然後重新建構它 --- *A database search is globally accessible and makes it possible to go directly to any object.* 資料庫搜尋是全域的，並且可以直接存取任何物件。 *There is no need for all objects to be interconnected, which allows us to keep the web of objects manageable.* 不需要所有物件都互連，就使我們能夠保持物件(網路)的可管理性。 *Whether to provide a traversal or depend on a search becomes a design decision, trading off the decoupling of the search against the cohesiveness of the association.* 無論式組織遍歷或是依賴查詢都變成了設計的決策，需要權衡搜尋的解耦性和關聯的內聚性。 *Should the Customer object hold a collection of all the Orders placed?* "顧客"物件應該儲存一個包含"訂單"物件的容器嗎? *Or should the Orders be found in the database, with a search on the Customer ID field?* 又或者"訂單"物件的取得需要透過查詢 Customer ID欄位取得? *The right combination of search and association makes the design comprehensible.* 正確組合上述的查詢以及關聯使程式的設計更易於理解。 --- *Unfortunately, developers don't usually get to think much about such design subtleties, because they are swimming in the sea of mechanisms needed to pull off the trick of storing an object and bringing it back - and eventually removing it from storage.* 不幸的是開發人員不常去思考這些設計的精妙之處，因為他們正徜徉在五花八門的資料儲存機制(技術)之中，思考著物件該如何巧妙得儲存、重建最後從儲存中移除。 --- *Now from a technical point of view, retrieval of a stored object is really a subset of creation, because the data from the database is used to assemble new objects.* 站在技術的角度，檢索已儲存得物件確實是創建物件的一種可能，組合這類新物件時需要從資料庫中取得相關的資料。 *Indeed, the code that usually has to be written makes it hard to forget this reality.* 事實上，這類程式碼通常需要寫的有一定的辨識程度，可讓人不容易忘記。 *But conceptually, this is the middle of the life cycle of an ENTITY.* 但概念上，這只不過是"實體"生命週期的中間過程而已。 *A Customer object does not represent a new customer just because we stored it in a database and retrieved it.* 舉例來說，我們會認為某個Customer物件不代表新客戶，只因我們曾將其儲存在資料庫中並檢索它 *To keep this distinction in mind, I refer to the creation of an instance from stored data as reconstitution.* 為了將這類區別牢記於心，我將此類從儲存資料創建實例的過程稱之為"重組"。 --- *The goal of domain-driven design is to create better software by focusing on a model of the domain rather than the technology.* 領域驅動設計的目標是透過專注於領域模型而不是技術來創建更好的軟體。 *By the time a developer has constructed an SQL query, passed it to a query service in the infrastructure layer, obtained a result set of table rows, pulled the necessary information out, and passed it to a constructor or FACTORY, the model focus is gone.* 當開發人員直接透過資料庫行為開始構築物件，如 SQL 查詢、將其傳遞給基礎設施層中的查詢服務、獲取結果、提取必要的資訊並將其傳遞給建構函數或 FACTORY 時，領域模型焦點就消失了。 *It becomes natural to think of the objects as containers for the data that the queries provide, and the whole design shifts toward a data-processing style.* 自然而然開發人員會視物件僅為資料庫查詢的載體一般，使整體的設計轉向資料處理風格。 *The details of the technology vary, but the problem remains that the client is dealing with technology, rather than model concepts.* 技術實現的細節各不相同，但主要問題是系統依舊處理的是技術問題而非改變(領域模型)概念。