领域模型

文章目录 DDD分层与传统三层区别 DDD分层详解 四层架构图 分层作用 领域对象 DDD编码实践 代码结构描述 领域模型注入仓储类的问题 DDD分层与传统三层区别 根据DDD领域驱动设计原则，对应的软件架构也需要做出相应的调整。 我们常用的三层架构模型划分为表现层，业务逻辑层，数据访问层等，在 DDD 分层结构中既有联系又有区别， 个人认为主要有如下异同： 在架构设计上，在 DDD 分层结构中将传统三层架构的业务逻辑层拆解为应用层和领域层 其中Application划分为很薄的一层服务，非核心的逻辑放到此层去实现，核心的业务逻辑表现下沉到领域层去实现，凝练为更为精确的业务规则集合，通过领域对象去阐述说明。 在建模方式上， DDD 分层的建模思维方式有别于传统三层 传统三层通常是以数据库为起点进行数据库分析设计，而 DDD 则需要以业务领域模型为核心建模（即面向对象建模方式），更能体现对现实世界的抽象。 故 在DDD分层凸显领域层的重要作用，领域层为系统的核心，包括所有的业务领域模型的抽象表达 。 在职责划分上，基础设施层涵盖了2方面内容 持久化功能，其中原三层架构的数据访问层下沉到基础设施层的持久化机制实现 通用技术支持，一些公共通用技术支持也放到基础设施层去实现。 DDD分层详解 四层架构图 在该架构中，上层模块可以调用下层模块，反之不行。即 Interface ——>

Repository是什么？ 马丁大叔的书上同样也有解释：它是衔接数据映射层和域之间的一个纽带，作用相当于一个在内存中的域对象映射集合，它分离了领域对象和数据库访问代码的细 节。Repository受DomainObject驱动，Repository用于实现不属于DomainObject的自身相关的，但又受 DomainObject约束的业务。如CRUD操作就不是领域模型要关注的业务，但是领域模型最终要映射为数据关系保存到数据库中。一个领域模型要有对 应的Repository来处理与数据层衔接过程。但不是所有的DomainObject对Repository约束是相同的，可能这个领域对象没有对应 Repository删除操作，而别外一个却有，所以我们经常使用的泛型Repository<T> 是不合适的。但是为了代码简洁重用，大家根据实际情况还是使用了简洁的IRepository<T>接口，就像我们有时为了简单直接把 POCO当DTO或VO使用了。如果不引入Repository，我觉得没有必要实现DAL层，因为DbContext本身就是DAL层，然后只要为 DbContext定义好接IDAL接口从而必免与BLL层的耦合。从这里就可以看出Repository与DAL的区别，一个受域业务驱动出现的，一个 是出于解除耦合出现的。 UnitOfWork 工作单元

http://www.cnblogs.com/mecity/archive/2011/07/17/2108508.html EF虽然是一个晚生畸形的ORM框架，但功能强大又具有灵活性的，给了开发人员一定的发挥空间。因为微软出发点总是好的，让开发变得简单，但实际上不是所有的事情都这么理想。这里顺便推荐马丁大叔的书《企业应架构模式》。 本节主要深入分析EF的分层问题，下面是本节的已列出的要探讨内容。 领域模型的概念 DbContext与Unit of Work 的概念 DbContext 创建实例及线程安全问题 不要随便using或Dispose DbContext DbContext的SaveChanges事务 Repository与UnitOfWork引入 DbContext T4模板的应用 EDM文件是放在DAL层还是Model层中？ EF MVC项目分层 一、领域模型的概念 领域模型：是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。 业务对象模型从业务角色内部的观点定义了业务用例。定义很商业，很抽象，也很理解。一个商业的概念被引入进来之后，引发很多争议和思考。而DomainObject 在我们实际的项目又演化成大致下面几种 1.纯事务脚本对象（只有字段的set,get)，没有任何业务（包括没有导航属性）

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 2019年参加了"领域驱动设计峰会2019"看到了国内、国外、不同行业在基于DDD的实践分享。 成年热学习的一个特点就是带着自己的经验来思考接收到的内容，那么回顾自己接触DDD有一段时间，将自己的经验和思考作用在项目上，真真切切替换了DDD带给我的提升。 本片内容将不会聚焦在哪些理论上，而是看看那些些提升我开发效率的技术部分（非具体代码的粒度）。 充血模型 代替 贫血模型 Domain + DomainService + ApplicationService 基础服务层 和业务保持一致 统一语言 01 用 充血模型 代替 贫血模型 充血模型的好处是让我最先感觉到收益的地方。 在之前的项目中很多都采用了三层的项目架构设计，短时间内看上去没有什么问题，但是随着项目的进行，Service层变得越来越臃肿，不得不加入其它的约束来让项目结构变得清晰。是的遇到问题、分析问题、解决问题。但是项目毕竟是个团队项目，所以有时候单个人遵守约束很容易，但是让团队都最受这种约束就变的困难的了，所以三层架构在原来的工作中确实带来了一部分问题。 是的，正如上面所言，在简单的场景下，采用贫血模型能够清楚的讲明白的。但是随着业务的丰富，想要通过代码接示业务意图变得异常的困难。 在接触DDD之后，项目开发中，领域模型使用了充血模型

领域驱动设计的关注重心是领域，尤其在面对复杂的领域逻辑时，它总能够帮助我们很好地分析领域。领域驱动设计的基础是领域建模。Eric认为需要和领域专家良好地合作，从交谈中发现通用语言，找到领域的关键词。领域建模是迭代的过程，根据逐渐深入的领域知识来精化模型。不过，领域驱动设计并不排斥其他的分析技术，例如分析模式，或者通过测试驱动开发来引导我们找到问题域的领域模型。 领域建模并非领域驱动设计所独有。在RUP中，领域建模就是一个非常重要的环节。它是一种用例驱动的开发方法，通过获得的用例来帮助分析和设计人员寻找对象，以及对象之间的关系。根据我个人的经验，我喜欢采用两种截然不同的方式来获得模型。一种是用例驱动，一种则是测试驱动。在得到初步的领域模型中，我会尝试利用领域驱动设计的思想为对象分类，找到实体、值对象、聚合以及服务对象，并通过分析对象的生命周期，为不同类型的对象建立资源库和工厂对象。 本文将以一个读者耳熟能详的图书馆管理系统作为我们要分析的领域，尝试讲解如何在项目开发中应用领域驱动设计。我将选择用例驱动的方式来获得我最初的领域模型。简单起见，我先给出分析领域的用例以及用例图。 借书：读者携带要借书籍到借书处。图书馆工作人员首先扫描读者的借书卡，获得读者信息，然后扫描书籍的条形码。如果借阅多本，则扫描多本书籍。扫描时，需要判断当前读者的类型，获得读者可借书籍数。如果借阅书籍超出，则提示

写好设计文档 怎样算一个好的设计文档 文档意图清晰，描述逻辑有序 动静结合，既有静态模型又有动态模型 注重分析生产活动的生命周期 列出能力矩阵 善于发现概念，将捕捉到的概念显示化，建立领域模型 划清边界，构建层次 有不同的视图，一图胜千言。比如有用例图，领域模型图，活动图，时序图，状态图，业务流程图，业务架构图，应用架构图，技术架构图等等。 静态建模 用例收集 用例是设计文档后续所有环节的输入，非常重要。 “处理配送订单”用例描述 用例名称：处理配送订单 概述：供应商请求一个配送订单；系统确定库存满足要求，并且显示订单。 参与者：供应商 前置条件：供应商需要处理一个配送订单并且一个配送订单存在。 主序列： 供应商请求下一个配送订单。 系统检索并且显示配送订单。 供应商为配送订单请求请求商品库存检查。 系统确定系统中的商品对于满足订单是可用的，并且保留这些商品。 系统给供应商显示库存信息，并且确认商品被保留。 可替换序列：步骤4：如果商品库存不存在，系统显示警告信息。 后置条件：系统为配送订单保留了库存商品。 分析生产活动的生命周期 任何业务都可以抽象为生产活动的过程，人们通过生产产品，供其他人消费。生产活动按照时间维度可以简化为生产前，生产中，生产后。 能力矩阵图 根据生命周期每个阶段梳理功能矩阵图 领域模型 发现概念：通过分析用例提取概念，用实体表示概念。 静态实体：作为生产资料

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 对于软件开发来说，领域建模是最重要的活动，领域模型是最重要的产物。领域模型反映了软件所要服务的现实业务领域的本质，体现了我们对业务领域的认识、理解和洞见。 领域模型应该是一切领域开发活动的出发点和依归。 本系列文章以组织结构的领域建模为例，演示领域建模的方法和技巧。 领域模型的重要性 领域模型的重要性体现在： 领域模型的正确性决定了软件在业务上的正确性。 领域模型代表我们对问题域——即软件所要服务的现实业务领域——的组成、结构、行为、机制和规则的认识和理解。模型错误就是对问题域的认识错误，根据错误的模型开发出来的软件（解决方案）必然错漏百出，不符合业务需要。正如同解数学题，如果我们对试题的理解是错误的，我们给出的答案必然是错的。正如同赛跑，如果方向错误了，跑得快是没有什么用的。高超的设计思想和编码技巧都无法弥补领域模型的缺陷。 领域模型的抽象性决定了软件在未来业务上的扩展性。 我们知道在问题域中，既存在共性，也存在个性。好的领域模型通过抽象和分解等等方式，既实现了共性，也使个性化成为可能。不好的领域模型，或者无法进行个性化扩展，或者扩展的成本很高，需要对系统进行伤筋动骨的改动。 好的领域模型既满足当前客户的需要，也支持相同领域其他客户的需要；既符合当前业务需要，也支持未来业务扩展的需要

（同步自 http://www.blogjava.net/AndersLin/archive/2006/06/15/53086.html ） <<Domain Driven Design>> 和<< Patterns of Enterprise Application Architecture >>，令Domain 这个词很火，也引起了广泛争论。我这里也乱谈一把。 什么是领域模型(Domain Model) 我以为Domain分两个含义：Domain Object和Domain Service。那么什么样的系统是面向Domain的系统，一个Domain Object和普通的符合OO原则的对象有什么区别；一个Domain Service和普通的Facade或者Manager对象有什么区别。 概念上，一个Domain Object和普通的符合OO原则的对象有声明区别：Domain Object是业务意义上，承载了业务数据（我据此认为所有Domain Object是有状态对象），从本质上说它直接来源于现实世界，没有技术层次上的考虑，“符合OO原则的对象”是用OO方法分析得到的，是基于计算机领域技术的（这样的对象可以是无状态的）；但反过来，符合OO的对象不一定反应DOMAIN 的OBJECT。 技术上，Domain Object是指那些包含需要被 透明持久化的属性 ，以及 相关业务逻辑

面向对象与领域建模 板桥里人 http://www.jdon.com 2006/12/6（转载请保留） 多变且复杂的需求 　　如果没有多变的需求，也许就没有今天的面向对象软件，我们曾经试图通过需求管理、需求跟踪等等管理方式约束和减少需求频繁更新带给软件的冲击，可是这样下去的结果只有一个：使得软件更加僵化；或者程序员更加 劳累。 　　需求不但多变，而且经常是不可能第一次就能掌握，需求反映了某个领域的专业知识，例如数学、管理、财务或 电子商务等等，每个特定案例需求又有其特别复杂之处，几乎没有人能够第一次接触就可以深入掌握这些专业领域的 需求本质，就是专门的建模专家也不例外。 　　既然需求是多变而且复杂的，所以，就不能使用“堵”式方法对其进行控制和管理，只能顺势而为，通过灵活多变的 以及迭代反复的方式逐步抓住需求，并且作为需求的实现软件系统必须能够迅速应对需求变化，需求变化有多快，软件 变化就有多快。 　　因此，对于多变的需求，我们的解决之道是：引入灵活多变的架构，面向对象OO架构正是应对多变需求而生，强调软件的可维护性 和拓展性，OO可能不是最好方式，但是目前是最合适的；对于复杂的需求，我们的解决之道是：委派专门的建模专家跟踪理解需求， 在需求和需求实现之间搭建桥梁，项目方法上采取多次迭代的敏捷软件开发方式，逐步了解学习掌握需求。 　　在这里稍微说明一下，很多人总是将软件和数学、管理

　　聚合和聚合根是领域模型里面很重要的一个概念，其实我们在从真实世界对业务对象进行识别和概念建模的时候，关注的就是聚合根，这才是我们真正要管理的业务对象。一个对象可能有多个层次，也可能有多个子实体，但是这些子实体都不可能孤立存在，它们必须依附于一个聚合根存在，它们和根节点具有同样的生命周期。 　　 如果一个客户消亡，客户联系方式，客户的多张银行账户信息将不再有任何意义。 如果一张采购订单头消失，那么采购订单明细没有任何存在的意义。客户，采购订单，发票这些从真实业务中转化过来的业务对象才是真正的领域核心对象。 这些对象可能在领域建模的时候会分解到多个Entity或Value Object，但是一定要意识到实际的聚合在哪里？ 我们真正关注的业务对象实体究竟有哪些？ 　　为什么如此强调领域模型，强调聚合根的概念，因此我们在关注领域模型的时候将有助于我们打破原有的关系型数据库的思维模式，转化为对象和领域的思维模式。可以看到领域建模和聚合根的思路正是既适合于关系型数据库，也适合NoSql数据库的建模思路。因为在NoSQL持久化的时候，我们看到采购订单就是一个对象，其它明细和关联信息都是这个对象下的子实体信息，采购订单应该作为一个对象整体进行查询和存储，我们并不关系NoSQL会如何去存储这个对象。让我们正在关注领域对象，而不是去关心如何持久化。 　　聚合Aggregate就是一组相关对象的集合