DDD - 概述 - 聚合 - 限界上下文 (四)

最重要的一句話

DDD的全部有相關理論中，只有一句是相當重要的，可是也是最容易被忽略和最難作到的，拋棄傳統的設計方式（思路）的思想，這句話起了決定性的做用，可是99%的人都忽略了或者在開始沒法正視或理解。

爲何說這句話是最重要的一句話，由於他是設計真正轉變的出發點。

基於具體的語義環境

首先，DDD的重點在於領域這個東西，領域的肯定必需要基於必定的環境的，簡單理解就是 必須同時具有主謂賓，好比：小明關愛小花；對於這句話的理解其實存在歧義，若是沒有具體的語義環境下可能有如下兩種理解方式：

　　1）.小明 關愛（關係愛護）小花

　　2）.小明關 愛 小花

　　。。。其餘你可能想到的語義。若是不肯定具體的語義環境 那麼就沒法肯定限界上下文，間接的就是沒法肯定聚合如何建立，由於沒有這個具體的語義環境就沒法肯定的限界上下文就沒法決定如何肯定聚合跟，誰是主（聚合跟）誰是次（實體），誰又是用做點綴、修飾用的（ValueObject）.

示例參考

再換一個示例：組織架構，這個幾乎全部的管理系統可能都會涉及，尤爲是OA之類的管理系統

　　不合理的方式：按照以往的凡是去設就是，根據組織架構的相關業務（邏輯），你確定噼裏啪啦的設計出來了幾張表，Role,RoleClaim,User,UserClaim,UserDetail,LoginLog,Department,...而後就相關也業務開發了，，，可是，你以爲這個和DDD有啥關係，沒一毛錢關係，你仍是依舊的沉浸在以往的條件反應式的思想中，長期以往的思惟方式已經讓你機械化的知道須要這麼作，那麼若是不從DDD的角度，你這麼作是徹底Oj8K的，是的，你作的徹底沒問題。可是從DDD角度是徹底大錯特錯的， 若是你有讀過 實現領域驅動設計 ，你可能會記得還有一句話就是 以用戶（使用者）的思想去思考，而不是繼續使用開發者個思惟角度去思考，也是由於這個緣由。

　　正確的作法是：首先肯定你當前要實現的業務功能，以此肯定邊界，好比，咱們打算開發的內容是，用戶角色管理，那麼這裏就突出了兩個對象一個動做，1）用戶；2）角色） 3）和一個動做管理，這就肯定了咱們的上下文對象 能夠肯定爲 UserRoleDbContext（通常的命名會直接明瞭的凸顯出具體的語義含義），

那麼這時候猜到了思考咱們的聚合跟 Entity 以及ValueObject的設計。因此，這裏咱們的聚合對象就是User,由於一個用戶能夠對應多個role,同時role這個對象若是在沒有具體的用戶的狀況下 他的存在也沒有任何意義,可是多個用戶可能有相同的角色，因此role能夠肯定爲entity（DDD中entity的定義，有具體的標識）

以上是本人在設計在開發中的總結，若是您以爲不合理請指教。謝謝。