XIAOSUO 记录个人学习的足迹

摘要：我们先回顾下上一讲，在事件风暴中，我们会根据一些业务操作和行为找出实体（Entity）或值对象（ValueObject），进而将业务关联紧密的实体和值对象进行组合，构成聚合，再根据业务语义将多个聚合划定到同一个限界上下文（BoundedContext）中，并在限界上下文内完成领域建模。 那你知道为什么要在限界上下文和实体之间增加聚合和聚合根这两个概念吗？它们的作用是什么？怎么设计聚合？这就是我们这一讲重点要关注的问题。 聚合 在 DDD 中，实体和值对象是很基础的领域对象。实体一般对应业务对象，它具有业务属性和业务行为；而值对象主要是属性集合，对实体的状态和特征进行描述。但实体和值对象都只是个体化的对象，它们的行为表现出来的是个体的能力。 那聚合在其中起什么作用呢？ 举个例子。社会是由一个个的个体组成的，象征着我们每一个人。随着社会的发展，慢慢出现了社团、机构、部门等组织，我们开始从个人变成了组织的一员，大家可以协同一致的工作，朝着一个最大的目标前进，发挥出更大的力量。 领域模型内的实体和值对象就好比个体，而能让实体和值对象协同工作的组织就是聚合，它用来确保这些领域对象在实现共同的业务逻辑时，能保证数据的一致性。 你可以这么理解，聚合就是由业务和逻辑紧密关联的实体和值对象组合而成的，聚合是数据修改和持久化的基本单元，每一个聚合对应一个仓储，实现数据的持久化。 聚合有一个聚合根和上下文边界，这个边界根据业务单一职责和高内聚原则，定义了聚合内部应该包含哪些实体和值对象，而聚合之间的边界是松耦合的。按照这种方式设计出来的微服务很自然就是“高内聚、低耦合”的。 聚合在DDD分层架构里属于领域层，领域层包含了多个聚合，共同实现核心业务逻辑。聚合内实体以充血模型实现个体业务能力，以及业务逻辑的高内聚。跨多个实体的业务逻辑通过领域服务来实现，跨多个聚合的业务逻辑通过应用服务来实现。比如有的业务场景需要同一个聚合的A 和 B 两个实体来共同完成，我们就可以将这段业务逻辑用领域服务来实现；而有的业务逻辑需要聚合 C 和聚合 D中的两个服务共同完成，这时你就可以用应用服务来组合这两个服务。 聚合根 聚合根的主要目的是为了避免由于复杂数据模型缺少统一的业务规则控制，而导致聚合、实体之间数据不一致性的问题。 传统数据模型中的每一个实体都是对等的，如果任由实体进行无控制地调用和数据修改，…… 阅读全文

摘要：这两个概念都是领域模型中的领域对象。它们在领域模型中起什么作用，战术设计时如何将它们映射到代码和数据模型中去？就是我们这一讲重点要关注的问题。 另外，在战略设计向战术设计过渡的这个过程中，理解和区分实体和值对象在不同阶段的形态是很重要的，毕竟阶段不同，它们的形态也会发生变化，这与我们的设计和代码实现密切相关。 接下来，我们就分别看看实体和值对象的这些问题，从中找找答案。 实体 我们先来看一下实体是什么东西？ 在 DDD中有这样一类对象，它们拥有唯一标识符，且标识符在历经各种状态变更后仍能保持一致。对这些对象而言，重要的不是其属性，而是其延续性和标识，对象的延续性和标识会跨越甚至超出软件的生命周期。我们把这样的对象称为实体。没理解？没关系！请继续阅读。 实体的业务形态 在DDD不同的设计过程中，实体的形态是不同的。在战略设计时，实体是领域模型的一个重要对象。领域模型中的实体是多个属性、操作或行为的载体。在事件风暴中，我们可以根据命令、操作或者事件，找出产生这些行为的业务实体对象，进而按照一定的业务规则将依存度高和业务关联紧密的多个实体对象和值对象进行聚类，形成聚合。你可以这么理解，实体和值对象是组成领域模型的基础单元。 实体的代码形态 在代码模型中，实体的表现形式是实体类，这个类包含了实体的属性和方法，通过这些方法实现实体自身的业务逻辑。在 DDD里，这些实体类通常采用充血模型，与这个实体相关的所有业务逻辑都在实体类的方法中实现，跨多个实体的领域逻辑则在领域服务中实现。 实体的运行形态 实体以 DO（领域对象）的形式存在，每个实体对象都有唯一的ID。我们可以对一个实体对象进行多次修改，修改后的数据和原来的数据可能会大不相同。但是，由于它们拥有相同的ID，它们依然是同一个实体。比如商品是商品上下文的一个实体，通过唯一的商品 ID 来标识，不管这个商品的数据如何变化，商品的 ID一直保持不变，它始终是同一个商品。 实体的数据库形态 与传统数据模型设计优先不同，DDD是先构建领域模型，针对实际业务场景构建实体对象和行为，再将实体对象映射到数据持久化对象。 在领域模型映射到数据模型时，一个实体可能对应 0 个、1个或者多个数据库持久化对象。 大多数情况下实体与持久化对象是一对一。在某些场景中，有些实体只是暂驻静态内存的一个运行态实体，它不需要持久化。比如，基于多个价格配置…… 阅读全文

摘要：在 DDD领域建模和系统建设过程中，有很多的参与者，包括领域专家、产品经理、项目经理、架构师、开发经理和测试经理等。对同样的领域知识，不同的参与角色可能会有不同的理解，那大家交流起来就会有障碍，怎么办呢？因此，在DDD中就出现了“通用语言”和“限界上下文”这两个重要的概念。 这两者相辅相成，通用语言定义上下文含义，限界上下文则定义领域边界，以确保每个上下文含义在它特定的边界内都具有唯一的含义，领域模型则存在于这个边界之内。你是不是感觉这么描述很抽象？没关系，接下来我会给你一一详细讲解。 在这之前，请你先看这样两个问题，这也是今天内容的核心。 为什么要提出限界上下文的概念（也就是说除了解决交流障碍这个广义的原因，还有更具体的吗）？ 限界上下文在微服务设计中的作用和意义是什么？ 什么是通用语言？ 为了更好地理解限界上下文，回答这两个问题，我们先从通用语言讲起。 怎么理解通用语言这个概念呢？在事件风暴过程中，通过团队交流达成共识的，能够简单、清晰、准确描述业务涵义和规则的语言就是通用语言。也就是说，通用语言是团队统一的语言，不管你在团队中承担什么角色，在同一个领域的软件生命周期里都使用统一的语言进行交流。 那么，通用语言的价值也就很明了了，它可以解决交流障碍这个问题，使领域专家和开发人员能够协同合作，从而确保业务需求的正确表达。 但是，对这个概念的理解，到这里还不够。 通用语言包含术语和用例场景，并且能够直接反映在代码中。通用语言中的名词可以给领域对象命名，如商品、订单等，对应实体对象；而动词则表示一个动作或事件，如商品已下单、订单已付款等，对应领域事件或者命令。 通用语言贯穿DDD的整个设计过程。作为项目团队沟通和协商形成的统一语言，基于它，你就能够开发出可读性更好的代码，将业务需求准确转化为代码设计。 下面我带你看一张图，这张图描述了从事件风暴建立通用语言到领域对象设计和代码落地的完整过程。 在事件风暴的过程中，领域专家会和设计、开发人员一起建立领域模型，在领域建模的过程中会形成通用的业务术语和用户故事。事件风暴也是一个项目团队统一语言的过程。 通过用户故事分析会形成一个个的领域对象，这些领域对象对应领域模型的业务对象，每一个业务对象和领域对象都有通用的名词术语，并且一一映射。 微服务代码模型来源于领域模型，每个代码模型的代码对象跟领域对象一一对应。 这…… 阅读全文

摘要：DDD的知识体系提出了很多的名词，像：领域、子域、核心域、通用域、支撑域、限界上下文、聚合、聚合根、实体、值对象等等，非常多。这些名词，都是关键概念，但它们实在有些晦涩难懂，可能导致你还没开始实践 DDD就打起了退堂鼓。因此，在基础篇中，我希望能带着你一起做好实践前的准备工作。 除此之外，这些名词在你的微服务设计和开发过程中不一定都用得上，但它可以帮你理解DDD 的核心设计思想和理念。而这些思想和理念，在 IT 战略设计、业务建模和微服务设计中都是可以借鉴的。 今天就围绕以上这些DDD 关键概念来彻底理清它们与微服务的关系，了解它们在微服务设计中的作用。今天重点了解 DDD的领域、子域、核心域、通用域和支撑域等重要概念。 如何理解领域和子域？ 我们先看一下汉语词典中对领域的解释：“领域是从事一种专门活动或事业的范围、部类或部门。”百度百科对领域的解释：“领域具体指一种特定的范围或区域。” 两个解释有一个共同点——范围。对了！领域就是用来确定范围的，范围即边界，这也是DDD 在设计中不断强调边界的原因。 在研究和解决业务问题时，DDD 会按照一定的规则将业务领域进行细分，当领域细分到一定的程度后，DDD 会将问题范围限定在特定的边界内，在这个边界内建立领域模型，进而用代码实现该领域模型，解决相应的业务问题。简言之，DDD的领域就是这个边界内要解决的业务问题域。 既然领域是用来限定业务边界和范围的，那么就会有大小之分，领域越大，业务范围就越大，反之则相反。 领域可以进一步划分为子领域。我们把划分出来的多个子领域称为子域，每个子域对应一个更小的问题域或更小的业务范围。 我们知道，DDD是一种处理高度复杂领域的设计思想，它试图分离技术实现的复杂度。那么面对错综复杂的业务领域，DDD是如何使业务从复杂变得简单，更容易让人理解，技术实现更容易呢？ 其实很好理解，DDD的研究方法与自然科学的研究方法类似。当人们在自然科学研究中遇到复杂问题时，通常的做法就是将问题一步一步地细分，再针对细分出来的问题域，逐个深入研究，探索和建立所有子域的知识体系。当所有问题子域完成研究时，我们就建立了全部领域的完整知识体系了。 我们来看一下上面这张图。这个例子是在讲如何给桃树建立一个完整的生物学知识体系。初中生物课其实早就告诉我们研究方法了。它的研究过程是这样的。 第一步：确定研究对象，即研究…… 阅读全文

摘要：我们知道，微服务设计过程中往往会面临边界如何划定的问题，微服务到底应该拆多小，不同的人会根据自己对微服务的理解而拆分出不同的微服务，于是大家各执一词，谁也说服不了谁，都觉得自己很有道理。那在实际落地过程中，很多项目在面临这种微服务设计困惑时，是靠拍脑袋硬完成的，上线后运维的压力就可想而知了。那是否有合适的理论或设计方法来指导微服务设计呢？当你看到这一讲的题目时，我想你已经知道答案了。没错，就是DDD。那么今天我就给你详细讲解下：“微服务设计为什么要选择领域驱动设计？” 软件架构模式的演进 在进入今天的主题之前，我们先来了解下背景。我们知道，这些年来随着设备和新技术的发展，软件的架构模式发生了很大的变化。软件架构模式大体来说经历了从单机、集中式到分布式微服务架构三个阶段的演进。随着分布式技术的快速兴起，我们已经进入到了微服务架构时代。 我们先来分析一下软件架构模式演进的三个阶段。 第一阶段是单机架构： 采用面向过程的设计方法，系统包括客户端UI 层和数据库两层，采用 C/S 架构模式，整个系统围绕数据库驱动设计和开发，并且总是从设计数据库和字段开始。 第二阶段是集中式架构： 采用面向对象的设计方法，系统包括业务接入层、业务逻辑层和数据库层，采用经典的三层架构，也有部分应用采用传统的SOA架构。这种架构容易使系统变得臃肿，可扩展性和弹性伸缩性差。 第三阶段是分布式微服务架构： 随着微服务架构理念的提出，集中式架构正向分布式微服务架构演进。微服务架构可以很好地实现应用之间的解耦，解决单体应用扩展性和弹性伸缩能力不足的问题。 我们知道，在单机和集中式架构时代，系统分析、设计和开发往往是独立、分阶段割裂进行的。 比如，在系统建设过程中，我们经常会看到这样的情形：A负责提出需求，B 负责需求分析，C 负责系统设计，D负责代码实现，这样的流程很长，经手的人也很多，很容易导致信息丢失。最后，就很容易导致需求、设计与代码实现的不一致，往往到了软件上线后，我们才发现很多功能并不是自己想要的，或者做出来的功能跟自己提出的需求偏差太大。 而且在单机和集中式架构这两种模式下，软件无法快速响应需求和业务的迅速变化，最终错失发展良机。此时，分布式微服务的出现就有点恰逢其时的意思了。 微服务设计和拆分的困境 那进入微服务架构时代以后，微服务确实也解决了原来采用集中式架构的单体应用的很多问题，…… 阅读全文

摘要：逆变（contravariant）与协变（covariant）是C#4新增的概念，许多书籍和博客都有讲解，我觉得都没有把它们讲清楚，搞明白了它们，可以更准确地去定义泛型委托和接口，这里我尝试画图详细解析逆变与协变。 变的概念 我们都知道.Net里或者说在OO的世界里，可以安全地把子类的引用赋给父类引用，例如： //父类 = 子类 string str = string; object obj = str;//变了 而C#里又有泛型的概念，泛型是对类型系统的进一步抽象，比上面简单的类型高级，把上面的变化体现在泛型的参数上就是我们所说的逆变与协变的概念。通过在泛型参数上使用in或out关键字，可以得到逆变或协变的能力。下面是一些对比的例子： 协变（Foo父类 = Foo子类 ）： //泛型委托： public delegate T MyFuncAT();//不支持逆变与协变 public delegate T MyFuncBout T();//支持协变 MyFuncAobject funcAObject = null; MyFuncAstring funcAString = null; MyFuncBobject funcBObject = null; MyFuncBstring funcBString = null; MyFuncBint funcBInt = null; funcAObject = funcAString;//编译失败，MyFuncA不支持逆变与协变 funcBObject = funcBString;//变了，协变 funcBObject = funcBInt;//编译失败，值类型不参与协变或逆变 //泛型接口 public interface IFlyAT { }//不支持逆变与协变 public interface IFlyBout T { }//支持协变 IFlyAobject flyAObject = null; IFlyAstring flyAString = null; IFlyBobject flyBObject = null; IFlyBstring flyBString = null; IFlyBint flyBInt = null; flyAObject = flyAString;//编译失败，IFly…… 阅读全文

摘要：什么是托管代码(managed code) 托管代码(Managed Code)就是中间语言(IL)代码，在公共语言运行库(CLR)中运行。编译器把代码编译成中间语言，当方法被调用时，CLR把具体的方法编译成适合本地计算机运行的机器码，并且将编译好的机器码缓存起来，以备下次调用使用。随着程序集的运行，CLR提供各种服务：内存管理，安全管理，线程管理，垃圾回收，类型检查等等。 托管代码是一microsoft的中间语言(IL)，他主要的作用是在.NET FRAMEWORK的公共语言运行库(CLR)执行代码前去编译源代码，也就是说托管代码充当着翻译的作用，源代码在运行时分为两个阶段： 源代码编译为托管代码,（所以源代码可以有很多种，如VB,C#,J#) 托管代码编译为microsoft的平台专用语言 编译器把代码编译成中间语言(IL)，而不是能直接在你的电脑上运行的机器码。中间语言被封装在一个叫程序集(assembly)的文件中，程序集中包含了描述你所创建的类，方法和属性(例如安全需求)的所有元数据。你可以拷贝这个程序集到另一台服务器上部署它。 托管代码在公共语言运行库(CLR)中运行。这个运行库给你的运行代码提供各种各样的服务，通常来说，他会加载和验证程序集，以此来保证中间语言的正确性。当某些方法被调用的时候，运行库把具体的方法编译成适合本地计算机运行的机械码，然后会把编译好的机械码缓存起来，以备下次调用。(这就是即时编译)随着程序集的运行，运行库会持续地提供各种服务，例如自动垃圾回收、运行库类型检查和安全支持等。这些服务帮助提供独立于平台和语言的、统一的托管代码应用程序行为。 Visual Basic .NET和C#只能产生托管代码。如果你用这类语言写程序，那么所产生的代码就是托管代码。如果你愿意，Visual C++ .NET可以生成托管代码。当你创建一个项目的时候，选择名字是以.Managed开头的项目类型。例如.Managed C++ application。 什么是非托管代码(unmanaged code) 非托管代码，直接编译成目标计算机码，在公共语言运行库环境的外部，由操作系统直接执行的代码，代码必须自己提供垃圾回收，类型检查，安全支持等服务。如需要内存管理等服务，必须显示调用操作系统的接口，通常调用Windows SDK所提供的API来实现内存管…… 阅读全文

摘要：反射是什么： 反射Reflection [rɪˈflekʃn] 提供描述程序集、模块和类型的对象（Type 类型）。 可以使用反射动态地创建类型的实例，将类型绑定到现有对象，或从现有对象中获取类型，然后调用其方法或访问其字段和属性。 如果代码中使用了特性，可以利用反射来访问它们。 有关更多信息，请参阅特性。 反射命名空间：System.Reflection typeof 运算符：用于获取某个类型的 System.Type 实例 GetType()：获取当前实例的 Type。 Type类常用属性 Assembly：获取在其中声明该类型的程序集。 对于泛型类型，则获取在其中定义该泛型类型的程序集。 Type类常用方法 GetMembers ：获取当前 Type 的成员（包括属性、方法、字段、事件等） GetConstructor ：获取当前 Type 的特定构造函数 GetMethods：获取当前 Type 的方法 MethodInfo 类：发现方法的属性并提供对方法元数据的访问。 为什么要反射(优点)： 需要访问程序元数据中的特性时。 有关详细信息，请参阅检索存储在特性中的信息。 检查和实例化程序集中的类型。 在运行时构建新类型。 使用 System.Reflection.Emit 中的类。 执行后期绑定，访问在运行时创建的类型上的方法。 请参阅主题 “动态加载和使用类型”。 反射提高了程序的灵活性和扩展性，降低耦合性，提高自适应能力。它允许程序创建和控制任何类的对象，无需提前硬编码目标类 反射的缺点 性能问题：使用反射基本上是一种解释操作，用于字段和方法接入时要远慢于直接代码。因此反射机制主要应用在对灵活性和扩展性要求很高的系统框架上，普通程序不建议使用 可以通过缓存优化提高性能 使用反射会模糊程序内内部逻辑：程序员希望在源代码中看到程序的逻辑，反射等绕过了源代码的技术，因而会带来维护问题。反射代码比相应的直接代码更复杂。 至于执行效率的话，还可以，因为它是一种强类型语言，执行效率不错。不过，建议将反射过后，保存进 cache中 反射怎么用 一般是用在反射配置以提高程序扩展、程序解耦 通过反调调用类的方法 框架中使用最多，例如MVC、WCF、WEBAPI、ORM、AOP等，这些框架就是通过反射设计，我们使用的时候可以灵活去配置文件、配置类、配置…… 阅读全文

摘要：泛型缓存字典是通过静态构造函数只被执行一次的调用机制，在首次执行时存好值，后面不再计算直接调用，以达到缓存下效果。 静态构造函数：静态构造函数用于初始化任何静态数据，或执行仅需执行一次的特定操作。 将在创建第一个实例或引用任何静态成员之前自动调用静态构造函数。 说人话就是：只有该类第一次被调用时执行一次静态构造函数，该类后面再继续被调用时都不会再去执行静态构造函数。（跟踪调试发现确实这样，编译器能识别） public class GenericCacheTest { public static void Show() { for (int i = 0; i 5; i++) { Console.WriteLine(GenericCacheint.GetCache()); Thread.Sleep(10); Console.WriteLine(GenericCachelong.GetCache()); Thread.Sleep(10); Console.WriteLine(GenericCacheDateTime.GetCache()); Thread.Sleep(10); Console.WriteLine(GenericCachestring.GetCache()); Thread.Sleep(10); Console.WriteLine(GenericCacheGenericCacheTest.GetCache()); Thread.Sleep(10); } } } /// summary /// 字典缓存： /// 原理：静态属性常驻内存，是key-value的hash存储，每次调用时需要去内存器查找要进行哈希运算 /// /summary public class DictionaryCache { private static DictionaryType, string _TypeTimeDictionary = null; static DictionaryCache()//静态构造函数 { Console.WriteLine(This is DictionaryCache 静态构造函数); _TypeTimeDictionary = new Dictio…… 阅读全文

摘要：内容导读 概述 当你声明一个变量背后发生了什么？ 堆和栈 值类型和引用类型 哪些是值类型，哪些是引用类型？ 装箱和拆箱 装箱和拆箱的性能问题 一、概述 本文会阐述六个重要的概念：堆、栈、值类型、引用类型、装箱和拆箱。本文首先会通过阐述当你定义一个变量之后系统内部发生的改变开始讲解，然后将关注点转移到存储双雄：堆和栈。之后，我们会探讨一下值类型和引用类型，并对有关于这两种类型的重要基础内容做一个讲解。 本文会通过一个简单的代码来展示在装箱和拆箱过程中所带来的性能上的影响，请各位仔细阅读。 二、当你声明一个变量背后发生了什么？ 当你在一个.NET应用程序中定义一个变量时，在RAM中会为其分配一些内存块。这块内存有三样东西：变量的名称、变量的数据类型以及变量的值。 上面简单阐述了内存中发生的事情，但是你的变量究竟会被分配到哪种类型的内存取决于数据类型。在.NET中有两种可分配的内存：栈和堆。在接下来的几个部分中，我们会试着详细地来理解这两种类型的存储。 三、存储双雄：堆和栈 为了理解栈和堆，让我们通过以下的代码来了解背后到底发生了什么。 public void Method1() { // Line 1 int i=4; // Line 2 int y=2; //Line 3 class1 cls1 = new class1(); } 代码只有三行，现在我们可以一行一行地来了解到底内部是怎么来执行的。 **Line 1：**当这一行被执行后，编译器会在栈上分配一小块内存。栈会在负责跟踪你的应用程序中是否有运行内存需要 **Line 2：**现在将会执行第二步。正如栈的名字一样，它会将此处的一小块内存分配叠加在刚刚第一步的内存分配的顶部。你可以认为栈就是一个一个叠加起来的房间或盒子。在栈中，数据的分配和解除都会通过LIFO (Last In First Out)即先进后出的逻辑规则进行。换句话说，也就是最先进入栈中的数据项有可能最后才会出栈。 **Line 3：**在第三行中，我们创建了一个对象。当这一行被执行后，.NET会在栈中创建一个指针，而实际的对象将会存储到一个叫做“堆”的内存区域中。“堆”不会监测运行内存，它只是能够被随时访问到的一堆对象而已。不同于栈，堆用于动态内存的分配。 这里需要注意的另一个…… 阅读全文