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，是因为在下发指标分解的时候，需要填写一个预留指标和多个下发指标，所以构成了一个树的结构，当然业务只有两级的

实践中，其实不需要两级，虽然看起来每次登记指标分解的时候，都需要输入预留指标和多个下发指标，但是他们从结构上没有关系，只是引用同一个批次构成了一个整体而已