ddd

1、引言 Module，即模块，是指提供特定功能的相对独立的单元。提到模块，你肯定就会想到模块化设计思想，也就是功能的分解和组合。对于简单问题，可以直接构建单一模块的程序。而对于复杂问题，则可以先创建若干个较小的模块，然后将它们组装、链接在一起，从而构成复杂的软件系统。 在DDD中，模块的用途也是如此，通过分解领域模型为不同的模块，以降低领域模型的复杂性，提高领域模型的可读性。 二、DDD中的模块 模块是一个笼统的概念，比较宽泛，为了正确发挥模块的威力，理解模块的概念就十分重要。下面我们从具体的问题着手，来尝试说明模块的概念。 就拿电商系统来说，维护一个订单，需要收货地址、购买商品、订单信息。这些信息是紧密相关的，不可独立存在。我们可以抽象出三个简单的聚合。那这些类该如何存放呢？是为每一个聚合创建一个文件夹存放还是放在同一个文件夹？我想答案不言而喻。 这三个聚合就是一个模块，一个客户模块。通过定义一个order文件夹，来将相关联的领域对象组合起来。 通过以上的举例说明，我们可以看到每个模块都是相对独立的功能单元。通过模块来组织和封装相关概念，来分解领域模型，以简化领域模型的复杂性。 但不要将模块与子域和限界上下文混淆。在复杂的领域模型中，为了对领域模型中进行准确建模，需要将领域模型拆分成多个子域，每个子域对应一个或多个限界上下文。在限界上下文中

1、引言 Module，即模块，是指提供特定功能的相对独立的单元。提到模块，你肯定就会想到模块化设计思想，也就是功能的分解和组合。对于简单问题，可以直接构建单一模块的程序。而对于复杂问题，则可以先创建若干个较小的模块，然后将它们组装、链接在一起，从而构成复杂的软件系统。 在DDD中，模块的用途也是如此，通过分解领域模型为不同的模块，以降低领域模型的复杂性，提高领域模型的可读性。 二、DDD中的模块 模块是一个笼统的概念，比较宽泛，为了正确发挥模块的威力，理解模块的概念就十分重要。下面我们从具体的问题着手，来尝试说明模块的概念。 就拿电商系统来说，维护一个订单，需要收货地址、购买商品、订单信息。这些信息是紧密相关的，不可独立存在。我们可以抽象出三个简单的聚合。那这些类该如何存放呢？是为每一个聚合创建一个文件夹存放还是放在同一个文件夹？我想答案不言而喻。 这三个聚合就是一个模块，一个客户模块。通过定义一个order文件夹，来将相关联的领域对象组合起来。 通过以上的举例说明，我们可以看到每个模块都是相对独立的功能单元。通过模块来组织和封装相关概念，来分解领域模型，以简化领域模型的复杂性。 但不要将模块与子域和限界上下文混淆。在复杂的领域模型中，为了对领域模型中进行准确建模，需要将领域模型拆分成多个子域，每个子域对应一个或多个限界上下文。在限界上下文中

概述 DDD（Domain-Driven Design 领域驱动设计）是由Eric Evans最先提出，目的是对软件所涉及到的领域进行建模，以应对系统规模过大时引起的软件复杂性的问题。整个过程大概是这样的，开发团队和领域专家一起通过 通用语言(Ubiquitous Language)去理解和消化领域知识，从领域知识中提取和划分为一个一个的子领域（核心子域，通用子域，支撑子域），并在子领域上建立模型，再重复以上步骤，这样周而复始，构建出一套符合当前领域的模型。 DDD概述 这里需要注意几点： 通用语言是一个很泛的概念，它作为一种沟通工具，在开发团队内部，开发团队与领域专家之间使用。它包含了自然语言、文档和图表（不一定是标准的UML图，只要能表达出领域知识的都可以）等内容。对通用语言中名词，动词的使用需要认真考量，因为这些名词和动词会作为后面模型的指导命名。 通用语言中定义的术语在一个 限界上下文(bounded context)中不能存在二义性。同一个事物在不同的限界上下文中因为所关注的侧重点不同，所以所表达出的概念是不同的，但在同一个限界上下文中应该表示的是一个概念。比如用户在微信中的聊天场景，朋友圈以及支付场景中所有表达的概念就应该是不同的，聊天场景关注的是用户间的聊天内容，而支付场景关注的是用户的账户余额。 一个子域可以包含多个限界上下文。 模型（Entity，值对象

一、前言 　 　在前面专题一中，我已经介绍了我写这系列文章的初衷了。由于dax.net中的DDD框架和Byteart Retail案例并没有对其形成过程做一步步分析，而是把整个DDD的实现案例展现给我们，这对于一些刚刚接触领域驱动设计的朋友可能会非常迷茫，从而觉得领域驱动设计很难，很复杂，因为学习中要消化一个整个案例的知识，这样未免很多人消化不了就打退堂鼓，就不继续研究下去了，所以这样也不利于DDD的推广。然而本系列可以说是刚接触领域驱动设计朋友的福音，本系列将结合领域驱动设计的思想来一步步构建一个网上书店，从而让大家学习DDD不再枯燥和可以看到一个DDD案例的形成历程。最后，再DDD案例完成之后，将从中抽取一个领域驱动的框架，从而大家也可以看到一个DDD框架的形成历程，这样就不至于一下子消化一整个框架和案例的知识，而是一步步消化。接下来，该专题将介绍的是：结合领域驱动设计的SOA架构来构建网上书店，本专题中并没有完成网上书店的所有页面和覆盖DDD中的所有内容，而只是一部分，后面的专题将会在本专题的网上书店进行一步步完善，通过一步步引入DDD的内容和重构来完成整个项目。 二、DDD分层架构 　　 从概念上说，领域驱动设计架构主要分为四层，分别为：基础设施层、领域层、应用层和表现层。 基础结构层：该层专为其他各层提供各项通用技术框架支持。像一些配置文件处理、缓存处理

1、引言 上次初步了解了什么是领域事件和为什么要使用领域事件的相关概念，接下来就要继续深入，如何对领域事件建模， 2、事件建模 事件建模也被称为事件风暴，形式有点类似于头脑风暴的方法,通过事件风暴的方法可以快速分析复杂业务领域，完成领域建模的目标。 事件风暴是一项团队活动，是在通过领域事件识别出聚合根，进而划分微服务的限界上下文。在活动中，团队先通过头脑风暴的形式罗列出领域中所有的领域事件，整合之后形成最终的领域事件集合，然后对于每一个事件，标注出导致该事件的命令（Command），再然后为每个事件标注出命令发起方的角色，命令可以是用户发起，也可以是第三方系统调用或者是定时器触发等。最后对事件进行分类整理出聚合根以及限界上下文。 事件风暴建模是基于领域驱动设计DDD的业务建模方式，它能够直接分析动态业务流程。动态的业务流程就是说在对于一个状态要做什么样的措施。事件风暴就是开发人员们一起讨论分析哪些状态需要建模领域事件(必须是有价值的)，事件建模的原则是不修改原本代码，保证代码的高度解耦。所以事件建模可以理解为封装，封装的原则就是以不变应万变，不变的是原本的业务，变的是对于业务执行后的状态的处理，例如订单从待付款变为已付款，这个业务本身不变，变的是将支付成功这个结果的应对方法。 建模事件需要知道事件的来源，有因必有果，建模事件必然是有原因和结果的，事件是由事件源和事件处理组合而成的

什么是领域驱动设计 领域驱动设计是Eric Evans 定义的一种发展理念， 软件中的复杂性：包含“某种程度上确实有用但无法解释如何运行但代码”。软件变得复杂及难以管理但一个主要原因在于，领域复杂性和技术复杂性混合在来一起。 复杂问题域产生的原因（泥球模式） 软件复杂性：偶发性技术复杂性和领域逻辑复杂性。 1.未使用通用语言创建的代码：对于公共语言和问题域知识缺乏重视会导致代码库可用但无法揭示业务目的，这会使得代码库难以阅读和维护，因为分析模型与代码模型之间的转译将会代价高昂且容易出错。备注：分析模型：分析模型用于描述一个软件应用程序的逻辑设计与结构。它可以由示意图或使用UML这样的建模语言来表示。它是软件的一种表现形式，让非技术人员能够概念化以便理解软件是如何构造的。 2.组织结构的缺乏：一个系统的最初体现是快速制作且通常能获得面面俱到的成功，但由于缺乏基于围绕问题域模型的应用程序设计的重视，后续的功能扩展就会变得很棘手。 泥球模式的危害 1.泥球模式将扼杀开发：开发团队会不断抱怨在如此一团混乱的情况下难以开展工作。开发速度的增长水平也无法满足业务需求。 2.缺乏对问题域的关注：当不能充分理解正在处理的业务领域时，软件项目就会失败。编码不应该是困难的哪一环，维持一个能够满足业务用例的有用软件模型才是难点所在。 什么是问题域 问题域涉及你当前正在构建软件的主题领域

EF Core已经出2.1版，开始考虑使用据传性能调优已经接近C++的.Net Core写新项目。想要抛弃以前使用asp.net那种sql脚本的码代码方式。同时找了一些开源的项目，比如ABP，SimpleCommerce。 其中ABP项目大而全，封装了很多模式，但文档更多是描述如何使用，如果自己不去看代码很容易不知所云。ABP项目基于Ioc( castle windsor )的动态代理特性实现了及其灵活的模块化方案，可以在运行过程中加载项目并初始化。同时ABP封装了自身的UnitofWork方式，结合了IoC框架太多特性 ( castle windsor )。 比如使用了该框架动态代理的实现，在业务执行之前插入UnitofWork相关逻辑。 而SimpleCommerce则利用了AutoFac以及asp.netcore的特性实现了模块化。对于仓储模式涉及的比较少。对于项目解耦可以说是一个简单的示例。 那么究竟要怎么开始EFCore项目？近期看到一篇，比较实用简单。 不，仓储或者说unit-of-work模式（简称 Rep/UoW）不再使用于EF Core。EF Core 已经实现了Rep/UoW模式，因此在ef core之上再抽象一层Rep/UoW模式，并无帮助。 比较明智的选择是直接使用EF Core，这样你可以使用EF Core 的全部功能，以实现高性能的数据库访问。

https://www.jb51.net/books/629970.html#downintro2 来源： https://www.cnblogs.com/mazhimazhi/p/11460200.html

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

1. DDD 领域驱动设计 首先是支撑微服务设计思想的DDD，这套理论讲述了如何划分微服务的子系统。 识别domain，领域模型 识别业务边界 画出UML图，结合领域专家共同进行领域建模，随着时间演进 领域驱动设计的实质 ：消化知识 建立领域模型 Tip 业务规则单独抽一层出来 利用策略模式 使业务规则更好阅读 from 领域驱动设计：软件核心复杂性对应之道 2.ADD 属性驱动设计 3.TDD 测试驱动开发 来源： https://my.oschina.net/xlpapapa/blog/3101095