從壹開始微服務 [ DDD ] 之二 ║ DDD入門 & 專案結構粗搭建

weixin_34337265發表於2018-10-23
微服務

前言

哈嘍大家好，今天是週二，我們的DDD系列文章今天正式開始講解，我這兩天一直在學習，也一直在思考如何才能把這一個系列給合理的傳遞給大家，並且達到學習的目的，還沒有特別好的路線，只是一個大概的模糊的安排，畢竟我沒有做過講師，但是我感覺還是需要對自己負責，至少要對得起這個熬夜寫的部落格吧 ?，我簡單設計了下整體流程，可能以後還會變動，不過大致方向是不會變的：

我打算通過一個最簡單一個例子來講，而且這個例子也是《實現領域驅動設計》這一本書的第一個小例子，至於為什麼要引用這個小栗子，我想的是，希望把整本書的大致精髓柔和到我這個 Project 中，最好給大家一個感覺，以後大家再看的的時候，不會感覺在天上飄飄然不知其所往，相反，是會感覺似曾相識，會感覺看過，不會那麼生硬無趣，這個就是我希望達到的兩個目的的其中之一：在瞭解並認識DDD領域驅動設計的情況下，也簡單的瞭解了這邊書的相關內容。

今天要說的是我們平時百分之百會遇到的，就是新建一個實體類，並對其進行CURD操作，看到這裡，你也許會胸有成竹的說，已經玩兒的很溜了，當然這是肯定的，今天不是說哪些新知識，而且說一下其實DDD驅動設計，已經在我們平時的開發中體現出來，當然又沒有完全貫徹下來（至少我是這麼一個），也說一下在我們的開發當中為什麼需要使用DDD領域驅動設計。

這裡說明下：今天搭建的是一個小雛形，我會以後慢慢細化，像上一個系列那樣，逐漸增加功能，差不多最後的框架是這樣的：

13652172-3baaf5bf497f87ef.png
image

零、今天要實現橙色的部分

13652172-fd2043caa8542cfa.png
image

一、為什麼要使用DDD

這個已經是老生常談了，相信大家也稍微或多或少的瞭解一些，在領域驅動設計中，我們的中心不在程式碼是開發技術上，而且在業務上，在這個設計中，會涉及到開發人員和領域專家（可能是專案管理者，或者部門經理，甚至是公司總經理，這些都可以算上領域專家），雖然在使用DDD的時候，需要我們在前期投入較多的時間和精力去考慮如何建模，已經開發過程中會遇到的各種問題，到那時這樣的投入是完全值得的，相信這個系列的結束，大家有一箇中肯的評價。

1、會增加我們專案的業務價值

在開發中，什麼是最寶貴的，當然是開發人員的時間效率最重要，然後還有就是溝通上，如果我們自己自定義的開發出一套程式碼，沒有一系列的業務模組，這樣的話，就是一個純技術的專案，雖然本來領域專家也看不懂，但是如果我們僅僅專注於技術方面，而沒有把業務人員的思想所對映到開發者中，那整個專案也只有可能僅僅是你成為這個領域專家，因為只有開發者當事人才能看懂。

這樣隨著時間的發展，隨著開發者當事人的離職或者轉向其他專案，本應該駐留在軟體中的領域知識也就丟失了。在以後的任何修改程式碼中，新的開發人員雖然可以重新和領域專家進行思想的溝通，但是之前開發的程式碼已經無法撼動，這也就是為什麼現在我們找工作的時候，不喜歡修改別人的程式碼，而且也會經常聽到這個情況：儘量不要修改原來的程式碼，自己新建一個，嗯，這個更是要命了的。

試想一下，如果我們把注意力重點放到了業務上，這樣就很清晰的進行迭代，而且也可以進一步的與領域專家進行對接。那我們的專案中都需要用到 DDD 領域驅動設計麼？答案當時是否定的，如果滿足以下幾點，我建議還是需要使用 DDD 吧：

1、如果你的系統中有30~40個使用者故事或者用例流的時候，軟體的複雜性就出來了。

這裡說明下使用者故事和用例流：就比如一個商城，我們有普通使用者，會員，公司管理員，企業合作伙伴，站長等等多個角色，當然還有其他的角色，每一個角色又會有一系列的操作，比如使用者會瀏覽商品，下單，修改個人資訊等等一系列的操作，這個就是用例流，這些角色所進行的全部操作，就是使用者故事。

2、如果你的系統現在不是很複雜，但是以後會複雜。就比如我們的商城後臺：本來是僅僅的對資料庫表的CURD，但是在真正的使用者（管理員）使用的時候，會發現在商品商家的時候，並不是很方便，需要用到價格規格表，或者發現商家資訊已經實現商品的多對多分配（現在可能是一對多），那想想後期的修改是很龐大的。

3、如果你的系統所在的領域不是很清晰，就連領域專家也不是很清晰，需要在未來幾年的慢慢討論，變化中前進的時候。

2、貧血症和失憶症

相信大家都聽過這兩個名詞，雖然聽著不是很舒服，但是卻天天在我們的手中被設計出來，如果你說不會，那好，請看下邊兩個情況是否在你的系統中出現（這裡說明下，這些栗子都是我現在手中的專案）：

1、你的領域物件（就是指實體類物件）是不是主要包含些共有的get 和 set，並且幾乎沒有業務邏輯？比如這樣：

  
    public class BlogArticle
    {
        public int bID { get; set; }
        public string bsubmitter { get; set; }
        public string btitle { get; set; }
        public string bcategory { get; set; }
        public string bcontent { get; set; }
        public int btraffic { get; set; }
        public int bcommentNum { get; set; }
        public DateTime bUpdateTime { get; set; }
        public System.DateTime bCreateTime { get; set; }
        public string bRemark { get; set; }
    }

2、你的軟體元件（就是指我們的方法定義）中是否經常會用到領域物件來實現一些業務邏輯，而且還是通過 get 和 set 的方式，直接將其拋給服務層或者應用層，甚至是直接拋到頁面上。

        //新增一個車票
        public ActionResult AddTicket(FormCollection form)
        { var TitleHead = form["TitleHead"].ToString(); var txtSubmitter = form["txtSubmitter"].ToString(); var TicketChannelOperateJson = form["TicketChannelOperateJson"].ToString(); try { if (!string.IsNullOrEmpty(TitleHead) && !string.IsNullOrEmpty(TicketChannelOperateJson) && !string.IsNullOrEmpty(txtSubmitter))
                {

                    Tickets tickets = new Tickets
                    {
                        Submiter = txtSubmitter,
                        SubmitDate = DateTime.Now,
                        SubmitData = TicketChannelOperateJson,
                        ActionType = Common.Enums.ActionType.Add,
                        ActionStatus = Common.Enums.ActionStatus.New,
                        Approver = "",
                        LastUpdateDate = DateTime.Now,
                        IsDelete = false,
                        IsCleanUp = false,
                        IsCheckIn = false,
                        TicketType = TicketType.Channel,
                    };

                    TicketsBLL ticketsBLL = new TicketsBLL(); bool flag = ticketsBLL.Add(tickets) > 0;
                }
            } catch (Exception e)
            {
                Logger.Log(e.InnerException + e.Message);
            }

        }

如果兩個情況你都說的是 NO ，那麼恭喜你，你的程式碼設計很健康，沒有檢查出來有貧血問題，如果你的回答中有一個 YES，那是不存在的，如果是兩個YES，我們就請繼續往下看吧。

二、貧血物件對我們做了什麼

如果你上邊的都已經看明白了，那我們就開始建我們的專案了，當然這裡要說明下，以後會對專案進行修繕，前幾章的程式碼可能很 low ，甚至是不好的，只是為了能說明問題。

1、新建一個 .net core web 專案

在指定的資料夾下，新建一個 Christ3D 解決方案，然後再新建一個 web 專案，具體過程相信大家都會了，如果不會，請會看第一個系列《系列教程一目錄：.netcore+vue 前後端分離》

13652172-8cb4502412a5f499.png
image

2、在Models 資料夾中，新增我們的領域物件 Customer.cs 和持久化虛擬類 CustomerDao.cs

   /// <summary>
    /// Customer 領域物件
    /// </summary>
    public class Customer
    {
        public string Id { get; set; }
        public string Name { get; set; }
        public string Email { get; set; }
        public DateTime BirthDate { get; set; }
    }


    /// <summary>
    /// 領域物件持久化層
    /// </summary>
    public class CustomerDao
    {
        public static Customer GetCustomer(string id)
        {
            return new Customer() { Id = "1", Name = "Christ", Email = "Christ@123.com" };
        }


        public static string SaveCustomer(Customer customer)
        {
            return "儲存成功";
        }
    }

3、在預設的 HomeController.cs 控制器中，新增儲存顧客方法 saveCustomer()

/// <summary>
/// 儲存顧客方法:add & update /// </summary>
/// <param name="id"></param>
/// <param name="name"></param>
/// <param name="email"></param>
/// <param name="birthDate"></param>
public void saveCustomer(string id, string name, string email, string birthDate)
{
    Customer customer = CustomerDao.GetCustomer(id); if (customer == null)
    {
        customer = new Customer();
        customer.Id = id;
    } if (name != null)
    {
        customer.Name = name;
    } if (email != null)
    {
        customer.Email = email;
    } //...還有其他屬性
 CustomerDao.SaveCustomer(customer);
}

到這裡，這就是一個領域 —— 對顧客領域物件進行儲存，這個功能還是很強大的，不管一個 Customer 是新增還是更新，甚至是不管名字換了，還是郵件重新申請了，都可以在這裡體現，相信這樣的方法我們都寫過，至少我是這樣。

這個方法真的很強大麼，這裡我們看一下，我們並不知道 saveCustomer() 的具體的應用場景（是後臺管理，還是前臺使用者自己操作，還是更新手機號等等），經過幾周或者幾年後，我們完全不知道當時建立這個方法的本來目的和意圖，當然你會說可以通過註釋的方法，我表示是反對的，我們對程式的設計，不能依賴於註釋，這是很可怕的。

還有，這些方法巢狀在一起，我們不能對其進行單元測試，都不用說細節，可能資料庫的約束就能對這個方法造成崩潰：比如時間欄位，比如字串長度過長，比如不能為空等，而且因為有很多地方呼叫這個看似功能強大的基方法，我們需要一個一個的往上游去研究，看看到底是哪個地方，哪個方法，哪個業務邏輯呼叫了，可能需要幾個小時的時間，甚至更久。

總結來說，上邊的 saveCustomer() 方法存在三個弊端：

1、saveCustomer() 方法的業務意圖不明確，當時我們為了貪圖功能的強大，把注意力都放到了技術上，從而忽略了業務核心。

2、saveCustomer() 方法的實現本來就增加了潛在的複雜性，雖然看著強大了，可是複雜度卻直線向上。

3、Customer 顧客領域物件根本不是物件，充其量就是一個資料持有者，僅僅是把我們的資料從持久化的資料庫中拿出來到內容的一個工具。

那既然如此，我們需要怎麼辦呢，沒錯，就是我們平時使用到的分層，一個專注領域業務的分層 —— DDD領域驅動設計，就出現了。

三、一切皆從領域開始 —— Domain

還記得下邊這個圖麼，這個是我上一篇文章中提到的《領域驅動設計架構圖》，我個人表示，這個圖已經很貼切和較為詳細的表示了DDD領域驅動設計是整體框架圖，大家從整體的箭頭走向就能看清楚（誰指向誰，表示前者依賴後者，後者實現前者），其中的內容我們都會說到，今天先簡單的把這個整體框架搭起來，至少先從什麼的DDD框架講起來——當然也就是從被依賴最多的領域層開始。

13652172-50256f8fb8728404.png
image

從上邊的文章中，我們知道了，在軟體開發中，我們已經把重點放到領域業務上，在上邊的 saveCustomer() 的方法中，所有的邏輯和用例都一股腦的放在一起，完全背離了這個思想，所以，那我們如果想要通過領域設計的思路來建立，會是怎麼樣的呢，請往下看。

1、定義領域物件 Customer.cs（值物件/聚合/根，以後會說）

在解決方案中，新建 .net core 類庫 Christ3D.Domain ，作為我們的領域層（這是一個臃腫的領域層，以後我們會把領域核心給抽象出來，現在簡化是為了說明），然後在該層下，新建 Models 資料夾，存放我們以後的全部領域物件，我們的專業領域設計，都是基於領域物件為基礎。

老張：這裡並沒有增加業務邏輯，以後會說明

 /// <summary>
    /// 定義領域物件 Customer /// </summary>
    public class Customer
    { protected Customer() { } public Customer(Guid id, string name, string email, DateTime birthDate)
        {
            Id = id;
            Name = name;
            Email = email;
            BirthDate = birthDate;
        } public Guid Id { get; private set; } public string Name { get; private set; } public string Email { get; private set; } public DateTime BirthDate { get; private set; }
    }

2、定義泛型介面 IRepository.cs

這裡說下為什麼開發中都需要介面層：

在層級結構中，上層模組呼叫下層模組提供的服務，這裡就會存在一種依賴關係，Rebort C. Martin提出了依賴倒置原則大致是如下：

上層模組不應該依賴於下層模組，兩者都應該依賴於抽象；

抽象不應該依賴於實現，實現應該依賴於抽象;

這是一個面向介面程式設計的思想。

在我們的領域層下，新建 Interfaces 資料夾，然後新增泛型介面

在我們專注的領域業務中，我們只需要定義該領域Customer 的相關用例即可（就比如如何CURD，如何發郵件等等，這些都是使用者角色Customer的用例流），而不用去關心到底是如何通過哪種技術來實現的，那種ORM去持久化的，這就是領域設計的核心，當然現在有很多小夥伴還是喜歡直接把介面和實現放在一起，也無可厚非，但是不符合DDD領域設計的思想。

可能這個時候你會說，領域層，定義介面和實現方法放在一起也可以嘛，現在我們是看不出來效果的，以後我們會在這裡說到領域驅動，領域通知，事件驅動等等知識點的時候，你就會發現，在Domain層來對介面進行實現是那麼格格不入，沒關係慢慢來~~~

    /// <summary>
    /// 定義泛型倉儲介面，並繼承IDisposable，顯式釋放資源 /// </summary>
    /// <typeparam name="TEntity"></typeparam>
    public interface IRepository<TEntity> : IDisposable where TEntity : class { /// <summary>
        /// 新增 /// </summary>
        /// <param name="obj"></param>
        void Add(TEntity obj); /// <summary>
        /// 根據id獲取物件 /// </summary>
        /// <param name="id"></param>
        /// <returns></returns>
 TEntity GetById(Guid id); /// <summary>
        /// 獲取列表 /// </summary>
        /// <returns></returns>
        IQueryable<TEntity> GetAll(); /// <summary>
        /// 根據物件進行更新 /// </summary>
        /// <param name="obj"></param>
        void Update(TEntity obj); /// <summary>
        /// 根據id刪除 /// </summary>
        /// <param name="id"></param>
        void Remove(Guid id); /// <summary>
        /// 儲存 /// </summary>
        /// <returns></returns>
        int SaveChanges();
    }

3、定義 Customer 領域介面 ICustomerRepository.cs

我們以後的每一個子領域中特有的介面，還是需要定義的，並且繼承自我們的泛型倉儲介面

    /// <summary>
    /// ICustomerRepository 介面 /// 注意，這裡我們用到的業務物件，是領域物件 /// </summary>
    public interface ICustomerRepository : IRepository<Customer> { //一些Customer獨有的介面
        Customer GetByEmail(string email);
 }

好了，這個時候我們的最最最簡單的領域層就搭建好了，裡邊有我們的子領域 Customer的相關介面實現，整體結構是這樣的：

13652172-5bd43b8edabea196.png
image

四、基礎層對領域進行實現 —— Infrastructure

上邊我們們定義了 Domian 領域層，這是一個介面層，那我們必須來實現它們，大家可以再往上看那個DDD領域驅動設計架構圖，你應該能找到，是誰對領域層進行了實現，答案當然是基礎設施層。

我們在解決方案下，新建一個 Christ3D.Infrastruct.Data 類庫，你一定會問，為什麼不直接是 Christ3D.Infrastruct ，反而在後邊還需要多一個 .Data 字尾呢，這裡要說的就是，在這個基礎設施層中，會有很多很多的內容，比如驗證層，IoC層，事務，工作單元等等，以後都會說到，至少從名字上你也能明白——基礎設施，這些基礎東西是不能放在領域層的，這是肯定的，因為我們關心的是業務領域，這個不是我們的業務，也不會是下文的應用層，至於為什麼，你可以先想一想，資料驗證和AOP這些為何不放在應用層。

1、新建泛型倉儲 Repository

Repository繼承了IRepository介面，這裡我們先不寫具體的實現，我們先定義好方法體，以後再慢慢填上，大家還記得如何快速的實現介面吧，Ctrl+. 可能有的小夥伴沒有這個功能，那就只能手動了。

13652172-e6ce76a298a31cbf.png
image
   /// <summary>
    /// 泛型倉儲，實現泛型倉儲介面
    /// </summary>
    /// <typeparam name="TEntity"></typeparam>
    public class Repository<TEntity> : IRepository<TEntity> where TEntity : class
    {
        public void Add(TEntity obj)
        {
            throw new NotImplementedException();
        }

        public void Dispose()
        {
            throw new NotImplementedException();
        }

        public IQueryable<TEntity> GetAll()
        {
            throw new NotImplementedException();
        }

        public TEntity GetById(Guid id)
        {
            throw new NotImplementedException();
        }

        public void Remove(Guid id)
        {
            throw new NotImplementedException();
        }

        public int SaveChanges()
        {
            throw new NotImplementedException();
        }

        public void Update(TEntity obj)
        {
            throw new NotImplementedException();
        }
    }

2、實現子領域Customer 倉儲

  /// <summary>
    /// Customer倉儲，操作物件還是領域物件 /// </summary>
    public class CustomerRepository : Repository<Customer>, ICustomerRepository
    { //對特例介面進行實現
        public Customer GetByEmail(string email)
        { throw new System.NotImplementedException();
        }
    }

最終結構

13652172-3e85dd324f714940.png
image

相信大家看到這裡，基本還是很輕鬆的，我們在領域層，把業務定義清楚，把領域物件設計好，然後在基礎層對其進行實現，是一個很好的過程，這麼看還是可以的。

但是一定會有小夥伴會看不慣這麼寫，他會說，領域設計定義介面我懂，那就定義，定義實現也可以，比如用 EFCore 或者其他 ORM 框架，那這樣直接在展示層呼叫不就好了，為啥還需要單拿出來一個應用 Application 層呢（等同於我們之前的 Service 層），到時候肯定又多出來一套介面和實現的過程，麻煩不麻煩？

我在上一個系列教程中，本來也是這麼嘗試使用DDD領域驅動設計，可以中間沒有看《實現領域驅動設計》這本書，導致出現了漏洞，也被各種小夥伴吐槽，這個系列就再證明一下吧，具體有什麼好處，或者說為什麼要在基礎設施層之上，再增加一個應用層（也就是我們的 Service 層），這裡先不說，下邊請繼續看。

五、定義系統的業務功能 —— Application

如果Repository 應用在應用層，會出現什麼情況：這樣就致使應用層和基礎層（我把資料持久化放在基礎層了）通訊，忽略了最重要的領域層，領域層在其中起到的作用最多也就是傳遞一個非常貧血的領域模型，然後通過 Repository 進行“CRUD”，這樣的結果是，應用層不變成所謂的 BLL（常說的業務邏輯層）才怪，另外，因為業務邏輯都放在應用層了，領域模型也變得更加貧血。

Application為應用層（也就是我們常說的 Service 層），定義軟體要完成的任務，並且指揮表達領域概念的物件來解決問題。這一層所負責的工作對業務來說意義重大，也是與其它系統的應用層進行互動的必要渠道。應用層要儘量簡單，不包含業務規則或者知識，而只為下一層中的領域物件協調任務，分配工作，使它們互相協作。它沒有反映業務情況的狀態，但是卻可以具有另外一種狀態，為使用者或程式顯示某個任務的進度。

1、檢視模型——Rich 領域模型（DTO以後說到）

在文章的最後，我們們再回顧下文章開頭說的貧血物件模型，相信你應該還有印象，這個就是對剛剛上邊這個問題最好的回答，如果我們直接把展示層對接到了基層設施層，那我們勢必需要用到領域模型來操作，甚至是對接到檢視裡，不僅如此，我們還需要驗證操作，傳值操作等等，那我們又把領域物件模型過多的寫到了業務邏輯裡去，嗯，這個就不是DDD領域驅動設計了，所以我們需要一個應用層，對外進行資料介面的提供，這裡要強調一點，千萬不要把應用層最後寫滿了業務邏輯，業務應該在領域層！！！

在專案根路徑下，新建 Christ3D.Application 類庫，作為我們的應用層，然後新建 ViewModels 資料夾，用來存放我們的基於UI 的檢視模型，它是如何來的，這個下邊說到。

 /// <summary>
    /// 子領域Customer的檢視模型 /// </summary>
    public class CustomerViewModel
    {
        [Key] public Guid Id { get; set; }

        [Required(ErrorMessage = "The Name is Required")]
        [MinLength(2)]
        [MaxLength(100)]
        [DisplayName("Name")] public string Name { get; set; }

        [Required(ErrorMessage = "The E-mail is Required")]
        [EmailAddress]
        [DisplayName("E-mail")] public string Email { get; set; }

        [Required(ErrorMessage = "The BirthDate is Required")]
        [DisplayFormat(ApplyFormatInEditMode = true, DataFormatString = "{0:yyyy-MM-dd}")]
        [DataType(DataType.Date, ErrorMessage = "Data em formato inválido")]
        [DisplayName("Birth Date")] public DateTime BirthDate { get; set; }
    }

這裡僅僅是增加了特性，更多的業務邏輯還是在 領域層 來實現的。

2、定義應用服務介面 ICustomerAppService，依賴抽象思想

在我們的應用層下，新建 Interfaces 資料夾，用來存放我們的對外服務介面，然後新增 Customer服務介面類，這裡要說明下，在應用層對外介面中，我們就不需要定義泛型基類了，因為已經沒有必要，甚至是無法抽象的，


    /// <summary>
    /// 定義 ICustomerAppService 服務介面
    /// 並繼承IDisposable，顯式釋放資源
    /// 注意這裡我們使用的物件，是檢視物件模型
    /// </summary>
    public interface ICustomerAppService : IDisposable
    {
        void Register(CustomerViewModel customerViewModel);
        IEnumerable<CustomerViewModel> GetAll();
        CustomerViewModel GetById(Guid id);
        void Update(CustomerViewModel customerViewModel);
        void Remove(Guid id);
    }

3、實現應用服務介面 CustomerAppService.cs ，對接基層設施層

在我們的應用層下，新建 Services 資料夾，用來存放我們對服務介面的實現類

   /// <summary>
    /// CustomerAppService 服務介面實現類,繼承 服務介面
    /// 通過 DTO 實現檢視模型和領域模型的關係處理
    /// 作為排程者，協調領域層和基礎層，
    /// 這裡只是做一個面向使用者用例的服務介面,不包含業務規則或者知識
    /// </summary>
    public class CustomerAppService : ICustomerAppService
    {
        private readonly ICustomerRepository _customerRepository;

        public CustomerAppService(ICustomerRepository customerRepository)
        {
            _customerRepository = customerRepository;
        }

        public IEnumerable<CustomerViewModel> GetAll()
        {
            return null;
            //return _customerRepository.GetAll().ProjectTo<CustomerViewModel>();
        }

        public CustomerViewModel GetById(Guid id)
        {
            return null;
            //return _mapper.Map<CustomerViewModel>(_customerRepository.GetById(id));
        }

        public void Register(CustomerViewModel customerViewModel)
        {
            //var registerCommand = _mapper.Map<RegisterNewCustomerCommand>(customerViewModel);
        }

        public void Update(CustomerViewModel customerViewModel)
        {
            //var updateCommand = _mapper.Map<UpdateCustomerCommand>(customerViewModel);
        }

        public void Remove(Guid id)
        {
            //var removeCommand = new RemoveCustomerCommand(id);
        }

        public void Dispose()
        {
            GC.SuppressFinalize(this);
        }
    }

目前這裡還沒有具體使用基礎層的倉儲，為什麼呢，因為應用層是面向檢視物件模型，不涉及到業務，而基礎設施層和領域層是基於 領域物件模型，面向業務的，所以我們需要用到 DTO ，這一塊以後我們會說到。

13652172-f78edd18221202da.png
image

六、結語

好啦，今天的講解基本就到這裡了，到目前為止，僅僅是實現了DDD領域驅動設計的第一個 D 領域模型，還沒有說到驅動的概念，通過經典的DDD四層，大家應該也瞭解了各層的作用，這裡有簡單的三個問題，不知道你是否已經真的看懂了，如果都能回答上來，恭喜！如果不是很確定，那抱歉，還需要再看看，或者查資料看書，或者來群裡諮詢我吧。

1、什麼是貧血物件模型？

2、我們的業務介面和業務實現，分別在哪一層？（ Answer：領域層和基礎設施層 ）

3、為什麼還需要定義一個應用層，而不是直接在應用層（Service層）對接基礎層（Repository層）？

好啦，週四我們會繼續推進，DDD 領域物件設計是如何實現 領域、子域、界限上下文的

七、Github & Gitee

https://github.com/anjoy8/ChristDDD

https://gitee.com/laozhangIsPhi/ChristDDD

相關文章