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应该没有问题,直接用“指标”翻译的

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

本栏目更多精彩内容:http://www.bianceng.cnhttp://www.bianceng.cn/Programming/project/

以上是小编为您精心准备的的内容,在的博客、问答、公众号、人物、课程等栏目也有的相关内容,欢迎继续使用右上角搜索按钮进行搜索数据
, 发给
, get
, public
, 登记
, 指标
, 面积
国家
,以便于您获取更多的相关知识。

时间: 2024-10-01 12:27:13

DDD领域驱动设计实践篇:如何提取模型的相关文章

DDD领域驱动设计:聚合、实体、值对象

关于具体需求,请看前面的博文:DDD领域驱动设计实践篇之如何提取模型,下面是具体的实体.聚合.值对象的代码,不想多说什么是实体.聚合等概念,相信理论的东西大家已经知晓了.本人对DDD表示好奇,没有在真正项目实践过,甚至也没有看过真正的DDD实践的项目源码,处于极度纠结状态,甚至无法自拔,所以告诫DDD爱好者们,如果要在项目里面实践DDD,除非你对实体建模和领域职责非常了解(很多时候会纠结一些逻辑放哪里好,属于设计问题)以及你的团队水平都比较高认同DDD,否则请慎重...勿喷! 代码在后,请先看D

浅谈我对DDD领域驱动设计的理解

从遇到问题开始 当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品.所以,自然而然就想到要做一个普通电商系统,用于实现在线销售自己企业产品的目的. 再比如,我是一家互联网公司,公司有很多系统对外提供服务,面向很多客户端设备.但是最近由于各种原因,导致服务经常出故障.所以,我们希望通过各种措施提高服务的质量和稳定性.其中的一个措施就是希望能做一个灰度发布的平台,这个

关于DDD领域驱动设计的理论知识收集汇总

最近一直在学习领域驱动设计(DDD)的理论知识,从网上搜集了一些个人认为比较有价值的东西,贴出来和大家分享一下: 我一直觉得不要盲目相信权威,比如不能一谈起领域驱动设计,就一定认为国外的那个Eric Evans写的那本书中的一些概念就一定是正确的,认为领域驱动设计就一定是聚合,聚合根,实体,值对象等概念.我们要有自己的思想,要有自己判断真正的领域模型该是什么样子的勇气和追求. "领域驱动设计" = "问题域模型驱动领域建模" + "领域建模驱动软件实现&q

DDD领域驱动设计基本理论知识总结

领域驱动设计之领域模型 加一个导航,关于如何设计聚合的详细思考,见这篇文章. 2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software (领域驱动设计),简称Evans DDD.领域驱动设计分为两个阶段: 以一种领域专家.设计人员.开发人员都能理解的通用语言作为相互交流的工具,在交流的过程中发现领域概念,然后将这些概念设计成一个领域模型: 由领域模型驱动软件设计,用代码来实现该领域模型

基于事件驱动的DDD领域驱动设计框架分享(附源代码)

补充:现在再回过头来看这篇文章,感觉当初自己偏激了,呵呵.不过没有以前的我,怎么会有现在的我和现在的enode框架呢?发现自己进步了真好! 从去年10月份开始,学了几个月的领域驱动设计(Domain Driven Design,简称DDD).主要是学习领域驱动设计之父Eric Evans的名著:<Domain-driven design:领域驱动设计:软件核心复杂性应对之道>,以及另外一本Martin Flower的<企业应用架构模式>,学习到了不少关于如何组织业务逻辑方面的知识.

DDD领域驱动设计 - 设计文档模板

设计文档模板: 系统背景和定位 业务需求描述 系统用例图 关键业务流程图 领域语言整理,主要是整理领域中的各种术语的定义,名词解释 领域划分(分析出子域.核心域.支撑域) 每个子域的领域模型设计(实体.值对象.聚合.领域事件,需要注意的是:领域模型是需要抽象的,要分析业务本质,而不是简单的直接对需求进行建模) 领域模型详细说明(如为什么这样设计的原因.模型内对象的关系.各种业务规则.数据一致性规则等) 领域服务.仓储.工厂设计 Saga流程设计 场景走查(讲述如何通过领域模型.领域服务.仓储.S

DDD领域驱动设计:领域服务

什么是领域服务,DDD书中是说,有些类或者方法,放实体A也不好,放实体B也不好,因为很可能会涉及多个实体或者聚合的交互(也可能是多个相同类型的实体),此时就应该吧这些代码放到领域服务中,领域服务其实就跟传统三层的BLL很相似,只有方法没有属性,也就没有状态,而且最好是用动词命名,service为后缀,但是真正到了实践的时候,很多时候是很难区分是领域实体本身实现还是用领域服务区实现的,除了那些需要操作(一般是参数了)多个实体的方法外,有些单个实体的操作是很难严格区分的,实际上放实体和领域服务都可以

DDD领域驱动设计:领域基础设施层

其实这里说的基础设施层只是领域层的一些接口和基类而已,没有其他的如日子工具等代码,仅仅是为了说明领域层的一些基础问题 1.领域事件简单实现代码,都是来至ASP.NET设计模式书中的代码 namespace DDD.Infrastructure.Domain.Events { public interface IDomainEvent { } } namespace DDD.Infrastructure.Domain.Events { public interface IDomainEventHa

领域驱动设计-相关理论

最近 Rafy 开源中心 启动刚一个月,在初始的讨论会上,成员们对面向对象设计.领域驱动设计等概念展开了大量的讨论. 下面我转载一篇文章,这篇文章的详细内容我都还没看完.不过,文章的结构正是我想要的!其结构非常清晰,很好地说明了领域驱动设计相关的起源.重点.模式.经典架构,以及一些后人扩展的新概念. 转载自<DDD领域驱动设计基本理论知识总结>,并稍微调整了一下内容顺序. 为什么面向对象比面向过程更能适应业务变化 对象将需求用类一个个隔开,就像用储物箱把东西一个个封装起来一样,需求变了,分几种