DDD領域驅動設計實踐篇之如何提取模型

需求說明：

• 省級用戶可以登記國家指標
• 省級用戶和市級用戶可以登記指標分解
• 登記國家指標時，需要錄入以下數據：指標批次、文號、面積，這里省略其他數據，下同
• 登記指標分解時，需要錄入以下數據：指標批次、文號、面積，以及可以選擇多個市（市級登記的時候是縣）的指標，每個市（縣）的指標也是要輸入批次、文號、面積
• 登記指標分解時，一個指標批次不能選擇多個相同的市（縣）
• 登記指標分解時，需要判斷當前剩余面積是否足夠，比如省登記的時候，要看國家本年度下發給省的指標面積是否大於省本年度所以指標面積，登記國家指標不需要這個判斷
• 指標登記完后，需要下發，下發后，對應的市縣才能看到數據
• 國家下發給省，省下發給本省和市，市下發給本市和縣，縣不能下發，只能查看市下發的數據
• 下發給下級的叫下發指標，下發給本級的叫預留指標
• 每次登記的年度都是用當前年度
• 每次登記都要生成一個項目編號，規則為100001+行政區+6位流水號

提取領域模型：

• 我們這里省略那些高大上的建模、什么共同語言等，直接進入話題，要的就是一個合理的模型，不管是怎么提取的，怎么抽象出來的，就是要一個結果
• 下面是我提取的模型，英文太爛，所以命名看起來很不舒服，歡迎拍磚

• /// <summary>
      /// 指標實體
      /// </summary>
      public class Indicators
      {
          /// <summary>
          /// ID
          /// </summary>
          public string Id { get; protected set; }
          /// <summary>
          /// 項目編號
          /// </summary>
          public string Number { get; set; }
          /// <summary>
          /// 面積
          /// </summary>
          public decimal Area { get; set; }
          /// <summary>
          /// 批次
          /// </summary>
          public decimal Batch { get; set; }
          /// <summary>
          /// 文號
          /// </summary>
          public decimal DocumentNumber { get; set; }
          /// <summary>
          /// 下發文號
          /// </summary>
          public decimal SubDocumentNumber { get; set; }
          /// <summary>
          /// 年份
          /// </summary>
          public int Year { get; set; }
          /// <summary>
          /// 當前用戶的行政區編碼
          /// </summary>
          public string CityCode { get; set; }
          
      }
  

  　　

模型說明：

• 類的命名用Indicators應該沒有問題，直接用“指標”翻譯的
• 至於為什么要Parent和Items，是因為在下發指標分解的時候，需要填寫一個預留指標和多個下發指標，所以構成了一個樹的結構，當然業務只有兩級的
• 實踐中，其實不需要兩級，雖然看起來每次登記指標分解的時候，都需要輸入預留指標和多個下發指標，但是他們從結構上沒有關系，只是引用同一個批次構成了一個整體而已