领域驱动设计

应广大网友的要求，我最近抽空基于ASP.NET MVC + WCF + Entity Framework做了一个案例，该案例以图书馆图书管理、读者借书、还书为业务背景，以领域驱动设计为思想指导，全程采用Microsoft技术进行实践，希望能够给Microsoft技术的狂热者以及领域驱动设计的学者提供实践参考。 本案例选用的业务逻辑非常简单，所以项目取名上我选用了“Tiny Library”，在后面一章我将详细介绍这个案例的业务逻辑、模型设计与系统架构。 下载案例 本来打算将项目发布到codeplex上，便于大家交流，也便于代码更新与维护，但由于某些原因，我无法在自己的网络环境中连接codeplex的svn/tfs服务，于是，目前只能以压缩包的形式发布案例源代码，希望大家谅解，等以后有机会更新到codeplex上后再通知大家。 【请单击此处下载案例源代码】 系统需求 Microsoft Visual Studio 2010 Microsoft Patterns & Practices 5.0（v5.0.414.0，Runtime v2.0.50727。请自行到Microsoft官方网站下载安装） Microsoft ASP.NET MVC 2 Microsoft Entity Framework（注意：是Visual Studio 2010自带的那个版本

模型对象的生命周期 - 工厂 首先应该认识到，是对象就有生命周期。这一点无论在面向对象语言还是在领域驱动设计中都适用。在领域驱动设计中，模型对象生命周期可以简要地用下图表示： 通过上图可以看到，对象通过工厂从无到有创建，创建后处于活动状态，此时可以参与领域层的业务处理；对象通过仓储实现持久化（也就是我们常说的“保存”）和重建（也就是我们常说的“读取”）。内存中的对象通过析构而消亡，处于持久化状态的对象则通过仓储进行撤销（也就是我们常说的“删除”）。整个状态转换过程非常清晰。 现在引出了管理模型对象生命周期的两种角色：工厂和仓储。同时也需要注意的是，工厂和仓储的操作都是基于聚合根（Aggregate Root）的，而不仅仅是针对实体的。关于仓储，内容会比较多，我在下一节单独讲述。在本节介绍一下工厂在.NET实体框架（EntityFramework）中的实现。 在打开了.NET实体框架自动生成的Entity Data Model Source Code文件后，我们发现，.NET实体框架为每一个实体添加了一个工厂方法，该方法包含了一系列原始数据类型和值类型的参数。比如，我们案例中的 Customer实体就有如下的代码： 隐藏行号 复制代码 ？ Customer Factory /// <summary> /// Create a new Customer object. /// <

目录 概述 直接看东西 什么是工作单元 如何实现工作单元 懒的模式 实现思路 落地代码 缺陷 总结 新年伊始，祝大家喜乐如意，爱和幸福“鼠”不尽！♫. ♪~♬.♩♫~ 概述 在上一篇 《如何运用领域驱动设计 - 存储库》 的文章中，我们讲述了有关仓储的概念和使用规范。仓储为聚合提供了持久化到本地的功能，但是在持久化的过程中，有时一个聚合根中的各个领域对象会分散到不同的数据库表里面；又或者是一个用例操作需要操作多个仓储；而这些操作都应该要么同时成功，要么同时失败，因此就需要为这一系列操作提供事务的支持，而事务管理就是由工作单元来提供的。在上一篇中，可能已经提到了工作单元，但是仅仅是一笔带过，现在我们就来详细的探究该如何更好的来实现工作单元。（文章的代码片段都使用的是 C# ,案例项目也是基于 DotNet Core 平台）。 直接看东西 在上一篇文章中，已经为大家提供了一个Github的Demo。如果已经下载过该Demo的同学，您现在直接进行Pull就可以获得最新的版本了；如果还没有下载该Demo的同学也可以戳下方的跳转链接获取。 GitHub 地址，点击直达哟 在这里我们可以先来看一下，该项目的应用代码是什么样子： [HttpPost] public ActionResult<string> Add() { //使用仓储来处理聚合 _itineraryRepository.Add(

DDD分层架构 Evans在它的《领域驱动设计：软件核心复杂性应对之道》书中推荐采用分层架构去实现领域驱动设计： image 其实这种分层架构我们早已驾轻就熟，MVC模式就是我们所熟知的一种分层架构，我们尽可能去设计每一层，使其保持高度内聚性，让它们只对下层进行依赖，体现了高内聚低耦合的思想。 分层架构的落地就简单明了了，用户界面层我们可以理解成web层的Controller，应用层和业务无关，它负责协调领域层进行工作，领域层是领域驱动设计的业务核心，包含领域模型和领域服务，领域层的重点放在如何表达领域模型上，无需考虑显示和存储问题，基础实施层是最底层，提供基础的接口和实现，领域层和应用服务层通过基础实施层提供的接口实现类如持久化、发送消息等功能。阿里巴巴开源的整洁面向对向分层架构COLA就采取了这样的分层架构来实现领域驱动。 改进DDD分层架构和DIP依赖倒置原则 DDD分层架构是一种可落地的架构，但是我们依然可以进行改进，Vernon在它的《实现领域驱动设计》一书中提到了采用依赖倒置原则改进的方案。 所谓的依赖倒置原则指的是：高层模块不应该依赖于低层模块，两者都应该依赖于抽象，抽象不应该依赖于细节，细节应该依赖于抽象。 image 从图中可以看到，基础实施层位于其他所有层的上方，接口定义在其它层，基础实施实现这些接口。依赖原则的定义在DDD设计中可以改述为

最近准备用SpringClound搭建一个微服务框架，因为对服务划分的细节比较纠结，在搜索资料的时候无意中留意到了“领域驱动设计”这个词，初步看了几篇博文，发觉跟自己认识的开发模式有很大的差别。 Martin Fowler在他的《企业应用架构模式》这本书中提出了两种开发方式“事务脚本”和“领域模型”，这两种开发分别对应了“贫血模型”和“充血模型”，我们习惯使用的MVC模式便是贫血模式。 在网上找了一篇详细介绍的博文，决心认真研读一番，读完补上读后感。 博文地址：http://www.cnblogs.com/netfocus/archive/2011/10/10/2204949.html 参考博文： https://blog.csdn.net/alex_xfboy/article/details/77334398 https://blog.csdn.net/alex_xfboy/article/details/77335982 https://blog.csdn.net/alex_xfboy/article/details/53609160 来源： https://www.cnblogs.com/wochenjun/p/9753843.html

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本文中的内容来自于Evans的<<领域驱动设计>>,学习笔记用; 软件的目标是实现业务价值; 领域驱动开发的重要性 在建模中学习相应的业务知识,团队明白业务,加快开发进程 使知识得到积累和传递 避免项目失败,更好实现业务价值 通用语言 模型要抽象了核心的业务知识.剔除掉无软件无关的知识. 模型包括uml图和伪代码等文档,模型要容易变动.对业务的认识不断深入. 通用语言进行沟通,开发人员和领域专家都明白的语言.扩展通用语言,加深对业务的理解,不断优化模型; 通用语言包括类和动作;要让领域专家明白模型和通用语言. 绑定模型和实现 模型要与编程结合,建模不应该与编程分离;代码要反映模型. 设计即开发,设计人员要参与开发,在开发中完善模型 面向对象语言是模型范式最好的实现. 来源： oschina 链接： https://my.oschina.net/u/1590027/blog/799220

本文算是《领域驱动设计》这本书的读书笔记，加上自己的一些读后感。网上有很多这本书的读书笔记，但是都是别人的，不如自己总结的理解深刻。建议大家在读这本书时结合《实现领域驱动设计》一起看，同时，一定要去实际建模和编码，理论联系实际才能得其精髓。 本文是【DDD】系列文章的第一篇，可参考： 使用领域驱动设计思想实现业务系统 定义 DDD是Domain driven design（领域驱动设计）的简称，是一种软件设计和开发的方法论，特别适用于复杂业务领域软件设计和开发。可参考wiki： Domain-driven_design 核心 将所有业务逻辑内聚到业务领域（domain）层，将设计和开发的关注点聚焦到业务领域； 建立通用的‘业务领域语言（Ubiquitous Language）’，Ubiquitous Language是工程师和业务领域专家（可以是产品经理、运营、业务相关人员）的桥梁； 战略上，通‘上下文（Bounded Context）’解耦各个业务系统/组件，通过‘防腐层（Anticorruption layer）’确保自有业务领域不受外界污染，通过‘开放主机服务（Open Host Service）’向外界公开服务； 战术上，将业务对象建模为entity和value object，entity有唯一业务标识且在其生命周期中状态可变，value object与之相反

一 为什么要有领域驱动设计？ 首先，计算机技术的作用（特别是软件技术）是为了解决现实世界某一个领域的问题，脱离了这些问题，单纯的算法，编程语言，或者操作系统都并没有实际的意义。但是开发人员往往只喜欢研究技术问题，而忽视了领域问题的学习。例如下面一个例子： “我要在这个项目中使用苹果公司新推出的Swift语言，在服务器端使用Hadoop，最好再尝试一下深度 学习方面的技术”，然后就一头扎进这些时髦和高大上的技术之中。三个月后，你去问他需要解决的领域中的真实问题是什么，他还是一脸茫然。” 这样的开发人员就是兴趣驱动型的开发人员。只追求技术，而忽视领域问题的软件，质量自然也是无法保证。 一个有力的观点指出了这一点：布鲁克斯老先生将维护软件的“概念完整性”作为软件开发的核心问题。软件之所以很复杂，难以维护，根本原因就在于软件概念的完整性遭到了破坏。甚至开发团队的成员从来就没有意识到有必要去维护软件概念的完整性，他们只是一些自行其是的开发人员，碰巧在于一个团队中一起堆代码而已。 当然，在实际的开发过程中，经常有软件概念完整性遭到破坏的情况发生，一部分原因是开发人员喜欢追求高大上的技术，产品功能对他们来说只是甲方提的需求，他只用考虑技术上能否实现。另一方面是产品设计人员缺乏相关的素质，他们只能进行表面功能的设计，而无法看到软件需要解决的核心问题

from: https://blog.csdn.net/ityouknow/article/details/81572072 领域驱动设计的概念 大家都知道软件开发不是一蹴而就的事情，我们不可能在不了解产品(或行业领域)的前提下进行软件开发，在开发前通常需要进行大量的业务知识梳理，然后才能到软件设计的层面，最后才是开发。而在业务知识梳理的过程中，必然会形成某个领域知识，根据领域知识来一步步驱动软件设计，就是领域驱动设计(DDD,Domain-Driven Design)的基本概念 。 为什么需要 DDD 在业务初期，功能大都非常简单，普通的 CRUD 就基本能满足要求，此时系统是清晰的。但随着产品的不断迭代和演化，业务逻辑变得越来越复杂，我们的系统也越来越冗杂。各个模块之间彼此关联，甚至到后期连相应的开发者都很难说清模块的具体功能和意图到底是啥。这就会导致在想要修改一个功能时，要追溯到这个功能需要修改的点就要很长时间，更别提修改带来的不可预知的影响面。 比如下图所示: 订单服务中提供了查询、创建订单相关的接口，也提供了订单评价、支付的接口。同时订单表是个大表，包含了非常多字段。我们在维护代码时，将会导致牵一发而动全身，很可能原本我们只是想改下评价相关的功能，却影响到了创建订单的核心流程。虽然我们可以通过测试来保证功能的完备性

我们都知道，很多业务系统都是基于 MVC 三层架构来开发的。实际上，更确切点讲，这是一种基于贫血模型的 MVC 三层架构开发模式。 虽然这种开发模式已经成为标准的 Web 项目的开发模式，但它却违反了面向对象编程风格，是一种彻彻底底的面向过程的编程风格，因此而被有些人称为反模式（ anti-pattern ）。特别是 领域驱动设计 （ Domain Driven Design ，简称 DDD ）盛行之后，这种基于贫血模型的传统的开发模式就更加被人诟病。而基于充血模型的 DDD 开发模式越来越被人提倡。 基于上面的描述，我们先搞清楚下面几个问题： 什么是贫血模型？什么是充血模型？ 为什么说基于贫血模型的传统开发模式违反 OOP ? 基于贫血模型的传统开发模式既然违反 OOP ，那又为什么如此流行？ 什么情况下我们应该考虑使用基于充血模型的 DDD 开发模式？ 什么是基于贫血模型的传统开发模式？ 对于大部分的后端开发工程师来说， MVC 三层架构都不会陌生。 MVC 三层架构中的 M 表示 Model ， V 表示 View ， C 表示 Controller 。它将整个项目分为三层：展示层、逻辑层、数据层。 MVC 三层开发架构是一个比较笼统的分层方式，落实到具体的开发层面，很多项目也并不会 100% 遵从 MVC 固定的分层方式，而是会根据具体的项目需求，做适当的调整。 比如