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，是由於在下發指標分解的時候，須要填寫一個預留指標和多個下發指標，因此構成了一個樹的結構，固然業務只有兩級的
• 實踐中，其實不須要兩級，雖然看起來每次登記指標分解的時候，都須要輸入預留指標和多個下發指標，可是他們從結構上沒有關係，只是引用同一個批次構成了一個總體而已