DDD领域驱动设计实践篇之如何提取模型

需求说明:

  • 省级用户可以登记国家指标
  • 省级用户和市级用户可以登记指标分解
  • 登记国家指标时,需要录入以下数据:指标批次、文号、面积,这里省略其他数据,下同
  • 登记指标分解时,需要录入以下数据:指标批次、文号、面积,以及可以选择多个市(市级登记的时候是县)的指标,每个市(县)的指标也是要输入批次、文号、面积
  • 登记指标分解时,一个指标批次不能选择多个相同的市(县)
  • 登记指标分解时,需要判断当前剩余面积是否足够,比如省登记的时候,要看国家本年度下发给省的指标面积是否大于省本年度所以指标面积,登记国家指标不需要这个判断
  • 指标登记完后,需要下发,下发后,对应的市县才能看到数据
  • 国家下发给省,省下发给本省和市,市下发给本市和县,县不能下发,只能查看市下发的数据
  • 下发给下级的叫下发指标,下发给本级的叫预留指标
  • 每次登记的年度都是用当前年度
  • 每次登记都要生成一个项目编号,规则为100001+行政区+6位流水号

提取领域模型:

  • 我们这里省略那些高大上的建模、什么共同语言等,直接进入话题,要的就是一个合理的模型,不管是怎么提取的,怎么抽象出来的,就是要一个结果
  • 下面是我提取的模型,英文太烂,所以命名看起来很不舒服,欢迎拍砖
  • /// <summary>
        ///
        /// </summary>
        public class Indicators
        {
            public Project()
            {
                Items = new List<Project>();
            }
    
            /// <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 int Year { get; set; }
            /// <summary>
            /// 当前用户的行政区编码
            /// </summary>
            public string CityCode { get; set; }
            /// <summary>
            /// 父级项目
            /// </summary>
            public Project Parent { get; set; }
            /// <summary>
            /// 下发项目
            /// </summary>
            public ICollection<Project> Items { get; set; }
        }

模型说明:

  • 类的命名用Indicators应该没有问题,直接用“指标”翻译的
  • 至于为什么要Parent和Items,是因为在下发指标分解的时候,需要填写一个预留指标和多个下发指标,所以构成了一个树的结构,当然业务只有两级的

DDD领域驱动设计实践篇之如何提取模型,布布扣,bubuko.com

时间: 2024-08-24 16:55:37

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

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

1.DDD领域驱动设计实践篇之如何提取模型 2.DDD领域驱动设计之聚合.实体.值对象 3.DDD领域驱动设计之领域基础设施层 什么是领域服务,DDD书中是说,有些类或者方法,放实体A也不好,放实体B也不好,因为很可能会涉及多个实体或者聚合的交互(也可能是多个相同类型的实体),此时就应该吧这些代码放到领域服务中,领域服务其实就跟传统三层的BLL很相似,只有方法没有属性,也就没有状态,而且最好是用动词命名,service为后缀,但是真正到了实践的时候,很多时候是很难区分是领域实体本身实现还是用领域

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

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

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

1.DDD领域驱动设计实践篇之如何提取模型 2.DDD领域驱动设计之聚合.实体.值对象 其实这里说的基础设施层只是领域层的一些接口和基类而已,没有其他的如日子工具等代码,仅仅是为了说明领域层的一些基础问题 1.领域事件简单实现代码,都是来至ASP.NET设计模式书中的代码 namespace DDD.Infrastructure.Domain.Events { public interface IDomainEvent { } } namespace DDD.Infrastructure.Dom

(转载)浅谈我对DDD领域驱动设计的理解

原文地址:http://www.cnblogs.com/netfocus/p/5548025.html 从遇到问题开始 当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品.所以,自然而然就想到要做一个普通电商系统,用于实现在线销售自己企业产品的目的. 再比如,我是一家互联网公司,公司有很多系统对外提供服务,面向很多客户端设备.但是最近由于各种原因,导致服务经常出故

WCF客户端配置以及代理-----基于DDD领域驱动设计的WCF+EF+WPF分层框架(4)

写在最前面:转载请注明出处 目录置顶: 关于项目--------------------基于DDD领域驱动设计的WCF+EF+WPF分层框架(1) 架构搭建--------------------基于DDD领域驱动设计的WCF+EF+WPF分层框架(2) WCF服务端具体实现---------基于DDD领域驱动设计的WCF+EF+WPF分层框架(3) WCF客户端配置以及代理-----基于DDD领域驱动设计的WCF+EF+WPF分层框架(4) Domain具体实现------------基于DD

DDD领域驱动设计仓储Repository

DDD领域驱动设计初探(二):仓储Repository(上) 前言:上篇介绍了DDD设计Demo里面的聚合划分以及实体和聚合根的设计,这章继续来说说DDD里面最具争议的话题之一的仓储Repository,为什么Repository会有这么大的争议,博主认为主要原因无非以下两点:一是Repository的真实意图没有理解清楚,导致设计的紊乱,随着项目的横向和纵向扩展,到最后越来越难维护:二是赶时髦的为了“模式”而“模式”,仓储并非适用于所有项目,这就像没有任何一种架构能解决所有的设计难题一样.本篇

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

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

基于DDD领域驱动设计的WCF+EF+WPF分层框架

目录置顶: 关于项目--------------------基于DDD领域驱动设计的WCF+EF+WPF分层框架(1) 架构搭建--------------------基于DDD领域驱动设计的WCF+EF+WPF分层框架(2) WCF服务端具体实现---------基于DDD领域驱动设计的WCF+EF+WPF分层框架(3) WCF客户端配置以及代理-----基于DDD领域驱动设计的WCF+EF+WPF分层框架(4) Domain具体实现------------基于DDD领域驱动设计的WCF+EF

C#进阶系列——DDD领域驱动设计初探(一)

前言:又有差不多半个月没写点什么了,感觉这样很对不起自己似的.今天看到一篇博文里面写道:越是忙人越有时间写博客.呵呵,似乎有点道理,博主为了证明自己也是忙人,这不就来学习下DDD这么一个听上去高大上的东西.前面介绍了下MEF和AOP的相关知识,后面打算分享Automapper.仓储模式.WCF等东西的,可是每次准备动手写点什么的时候,就被要写的Demo难住了,比如仓储模式,使用过它的朋友应该知道,如果你的项目不是按照DDD的架构而引入仓储的设计,那么会让它变得很“鸡肋”,用不好就会十分痛苦,之前