Merge branch 'master' of 47.103.61.198:darren/DDWiki

实践/后端/项目/24.DDD领域驱动基本概念.md

@@ -0,0 +1,259 @@
+>  领域驱动设计
+- 思想体系
+   - DDD 是一种开发思想体系，旨在管理为复杂问题域编写的软件的创建和维护工作。
+   - 专注领域要高于其他一切需求。
+   - DDD是模式、原则和实践的集合，可以被用到软件设计以管理
+- 模式类型
+   - 战略模式：对任何应用程序都有用 重点提炼问题域（核心子域）->塑造应用程序架构
+   - 战术模式：用于实现富领域模型（只当模型在领域逻辑做够丰富时才有用）
+- 实践原则
+   - 专注于核心领域 强调在核心子域付出最多努力的需要
+   -  通过协作学习 开发团队与业务专家的协作
+   - 通过探索和实验来创建模型 
+   - 通信 公共语言（UL）
+   - 理解模型的活用性 语言边界，避免歧义
+   - 让模型持续发展 持续致力与知识提炼
+
+> 通用语言
+- 抛开DDD 想到通用语言首先想到英语 特点：1）简单易学 2）使用效率高 3）国际通用
+- 概念：通过团队交流达成共识的能够准确传递业务规则的简单的语言
+- 价值 解决了交流障碍问题，使领域专家和开发人员协同合作
+
+> 领域（重在范围的界限)
+- 本质 ：可以理解为 就是一个问题域，只要是同一个领域，那问题域就相同。所以，只要我们确定了系统所属的领域，那这个系统的核心业务，既要解决的关键问题、问题的范围边界就基本确定了。
+- 与传统开发过程的区别在于 DDD注重领域建模
+- 领域拆分： 子域、核心域、通用子域、支撑子域
+- 举个例子（比如创建个电商网站 需要涉及的业务。商品、用户、订单、报价、支付、物流、保修相关业务）
+   - 大致拆分：商品子域、用户子域、销售子域、订单子域、支付子域、物流子域、维修子域
+   - 确定核心域：开发电商网站的目的是为了寻求推广和销售利润的最大化。所以核心域就是销售子域。
+   - 通用子域：服务服务于整个业务领域。-》日志子域  可以为该网站提供一个日志系统，来记录一些日志。我们可以设计一个日志子域来供其他子域使用。
+   - 支撑子域：作用于业务系统的某些重要业务而非核心业务，它关注于业务的某一方面，来支撑完善业务系统。
+      - 我们划分的子域中除了销售子域，其他都可以说是支撑子域。
+      - 比如物流子域，就是专注于物流相关业务，支撑着订单发货以及物流跟踪的重要流程。
+
+
+> 界限上下文
+- 可拆分为两个词，界限和上下文。 界限是指一个界限，具体的某一个范围。 上下文可理解为语境。
+- 例子 还是上述（电子商务）例子
+    - 在销售子域和商品子域中就是商品
+    - 在物流子域中特质货物，只关注部分属性
+- 命名 领域名+上下文 销售上下文 物流上下文
+
+> 领域模型
+- 概念：描述正在解决的问题及提出的解决方案
+- 特征：
+   - 综合了系统分析和设计
+   - 语言、模型、代码 三者紧密绑定
+   - 可以通过UML类图来展示
+- 例子 在线商城案例
+```
+Customer
+public class Customer
+{
+    public int Id{get;set;}
+    public string Name{get;set;}
+    public string BillingAddress{get;set;}
+    public string DeliveryAddress{get;set;}
+    Public string LoginName{get;set;}
+    public string LoginPassword{get;set;}
+    public string DayOfBirth{get;set;}
+}
+order
+public class Order
+{
+    public int Id{get;set;}
+    public string CreatedDate{get;set;}
+    public string CreatBy{get;set;}
+}
+OrderLine
+public class OrderLine
+{
+    public int Id{get;set;}
+    public string Quantity{get;set;}
+    public string Discount{get;set;}
+}
+Category
+public class Category
+{
+    public int Id{get;set;}
+    public string Name{get;set;}
+    public string Description{get;set;}
+}
+CreditCard
+public class CreditCart
+{
+    public int Id{get;set;}
+    public string Number{get;set;}
+    public string HolderName{get;set;}
+    public string ExpirationDate{get;set;}
+}
+Item
+public class Item
+{
+    public int Id{get;set;}
+    public string Name{get;set;}
+    public string Description{get;set;}
+    public string PurchasePrice{get;set;}
+    public string SalesPrice{get;set;}
+
+}
+```  
+
+> 实体 （Entity）
+- 概念： 唯一身份标识+可变性[状态（属性）+行为（方法或领域事件或领域服务）]
+-  唯一标识： 针对上述例子 抽象出User实体 要定义其唯一标识。
+   - 性格、外貌、昵称、身份证号都可以是User的属性，但为了确保标识的稳定性，智能用身份证号设为唯一身份标识。
+   - 唯一标识的类型
+      - 一个简单的应用程序里，一个int类型的自增Id就可以作为唯一标识。优点就是占用空间小，查询速度快。
+      - 而在一些业务当中，要求唯一标识有意义，通过唯一标识就能识别出一些基本信息，比如支付宝的交易号，其中就包含了日期和用户ID。这种就属于字符串类型的标识，这就对唯一标识的生成提出了挑战。
+
+   - 唯一标识的生成时机 
+     - 即时生成，即在持久化实体之前，先申请唯一标识，再更新到数据库。
+     - 延迟生成，即在持久化实体之后。
+   -  委派标识和领域标识
+     - 基于领域实体概念分析确定的唯一身份标识，我们可以称为领域实体标识
+     - 实现层超类型
+       - 定义层超类型接口
+       ```
+       public interface IEntity
+       {
+
+       }
+       public interface IEntity<TPrimaryKey> : IEntity
+       {
+           TPrimaryKey Id { get; set; }
+       }
+
+       ```
+       - 实现层超类型
+       ```
+       public class Entity : Entity<int>, IEntity
+       {
+
+       }
+       public class Entity<TPrimaryKey> : IEntity<TPrimaryKey>
+       {
+            public virtual TPrimaryKey Id { get; set; }
+            public override bool Equals(object obj)
+            {
+                if (obj == null || !(obj is Entity<TPrimaryKey>))
+                {
+                    return false;
+                }
+                if (ReferenceEquals(this, obj))
+                {
+                    return true;
+                }
+                var other = (Entity<TPrimaryKey>) obj;
+                var typeOfThis = GetType();
+                var typeOfOther = other.GetType();
+                if (!typeOfThis.GetTypeInfo().IsAssignableFrom(typeOfOther) && !typeOfOther.GetTypeInfo().IsAssignableFrom(typeOfThis))
+                {
+                    return false;
+                }
+                return Id.Equals(other.Id);
+            }
+            public override int GetHashCode()
+            {
+                 return Id.GetHashCode();
+            }
+            public static bool operator ==(Entity<TPrimaryKey> left, Entity<TPrimaryKey> right)
+            {
+                if (Equals(left, null))
+                {
+                   return Equals(right, null);
+                }
+                return left.Equals(right);
+            }
+            public static bool operator !=(Entity<TPrimaryKey> left, Entity<TPrimaryKey> right)
+            {
+                return !(left == right);
+            }
+       }
+       ```
+    - 可变性 
+      - 实体的状态 eg:订单状态：未支付、正常、已发货、关闭
+      - 实体的行为 eg：订单行为：支付、发货、关闭
+
+
+> 值对象
+- 概念：值+对象=》将一个值用对象的方式进行标书，表达一个具体的固定不变的概念
+- 值特征：
+    - 表示一个具体的概念
+    - 通过值得属性对其识别
+    - 属性判断
+    - 固定不变
+- 案例分析（购物网站都会维护客户收货地址信息来进行发货处理，一个地址信息一般主要包含省份、城市、区县、街道、邮政编码信息。）
+   - 地址是一个值，不会随着时间而变化，它包含了地址所需要的完整属性（省份、城市、区县、街道、邮政编码）
+   ```
+   public class Address
+   {
+        /// <summary>
+        /// 省份
+        /// </summary>
+        public string Province { get; private set; }
+
+        /// <summary>
+        /// 城市
+        /// </summary>
+        public string City { get; private set; }
+
+        /// <summary>
+        /// 区县
+        /// </summary>
+        public string County { get; private set; }
+
+        /// <summary>
+        /// 街道
+        /// </summary>
+        public string Street { get; private set; }
+
+        /// <summary>
+        /// 邮政编码
+        /// </summary>
+        public string Zip { get; private set; }
+
+        public Address(string province, string city,
+        string county, string street, string zip)
+        {
+            this.Province = province;
+            this.City = city;
+            this.County = county;
+            this.Street = street;
+            this.Zip = zip;
+        }
+
+        public override bool Equals(object obj)
+        {
+            bool isEqual = false;
+            if (obj != null && this.GetType() == obj.GetType())
+            {
+                var that = obj as Address;
+                isEqual = this.Province == that.Province
+                    && this.City == that.City
+                    && this.County == that.County 
+                    && this.Street == that.Street 
+                    && this.Zip == that.Zip;
+            }
+            return IsEqual;
+        }
+        public override int GetHashCode()
+        {
+            return this.ToString().GetHashCode();
+        }
+        public override string ToString()
+        {
+            string address = $"{this.Province}{this.City}" +
+                  $"{this.County}{this.Street}({this.Zip})";
+            return address;
+
+        }      
+   }
+   ```
+   - 作用
+     - 符合通用语言，更简单明了的表达简单业务概念
+     - 简化设计，减少不必要的数据库表设计
+       - 值对象不会孤立存在，可作为所属实体的数据列
+       - 多个值对象序可以劣化到单个列
+
+

实践/后端/项目/25.DDD仓储工厂等概念.md

@@ -0,0 +1,310 @@
+> 应用服务&领域服务
+
+- 服务是行为的抽象
+- 应用层（Application）：负责展现层与领域层之间的协调，协调业务对象来执行特定的应用程序任务。它不包含业务逻辑。
+- 领域层（Domain）：负责表达业务概念，业务状态信息以及业务规则，是业务软件的核心。
+
+- 应用服务：表达用例和用户故事的主要手段  eg：购物车结算=》应用行为
+    -  应用层通过应用服务接口来暴露系统的全部功能。在应用服务的实现中，它负责编排和转发，它将要实现的功能委托给一个或多个领域对象来实现，它本身只负责处理业务用例的执行顺序以及结果的拼装。通过这样一种方式，它隐藏了领域层的复杂性及其内部实现机制。
+
+- 领域服务 实现了全部业务逻辑并且通过各种校验手段保证业务正确性
+  - 当领域中的某个操作过程或转换过程不是实体或值对象的职责时，我们便应该将该操作放在一个单独的接口中，即领域服务。请确保该服务和通用语言时一致的；并且保证它是无状态的。
+  - 领域服务是用来协调领域对象完成某个操作，用来出路业务逻辑，它本身是一个行为，所以是无状态的。状态由领域对象保存。
+  - eg：比如转账操作问题 业务用例
+     - 1.检查账号余额是否足够
+     - 2.检查目标账户账号是否合法
+     - 3.转账
+     - 4.短信通知转账双方
+- 总结：
+  - 1.服务是行为的抽象
+  - 2.应用服务通过委托领域对象和领域服务来表达用例和用户故事。
+  - 3.领域对象（实体和值对象）负责单一操作。
+  - 4.领域服务用于协调多个领域对象共同完成某个业务操作。
+  - 5.应用服务不处理业务逻辑，领域服务处理业务逻辑。
+
+
+> 领域事件
+
+- 领域事件作为领域模型的重要部分，是领域建模的工具之一。
+- 用来捕获领域中已经发生的事情
+- 并不是领域中所有发生的事情都要建模为领域事件，要忽略无业务价值的事件
+- `当用户在购物车点击结算时，生成待付款订单，若支付成功，则更新订单状态为已支付，扣减库存，并推送捡货通知信息到捡货中心。 订单支付成功就是一个领域事件 `
+
+
+- 建模领域事件
+   - 使用领域事件来解耦方法：当然是封装不变，应对万变。上例 不变的是订单支付成功这个事件，变化的是针对这个事件不同处理手段。
+
+   - 抽象事件源 事件源应该至少包含事件发生的时间和触发事件的对象。
+   ```
+   public interface IEventData
+   {
+       /// <summary>
+       /// 事件发生的时间
+       /// </summary>
+       DateTime EventTime{get;set;}
+
+       /// <summary>
+       /// 触发事件的对象
+       /// </summary>
+       object EventSource{get;set;}
+   }
+   通过实现IEventData我们可以根据自己的需要添加自定义的事件属性。
+   ```
+   - 抽象事件处理
+    ```
+     针对事件处理 提取IEventHandler接口
+
+     /// <summary>
+     /// 定义事件处理器公共接口，所有的事件处理都要实现该接口
+     /// </summary>
+     public interface IEventHandler
+     {
+
+     }
+     事件处理要与事件源进行绑定，所以我们再来定义一个泛型接口
+
+     /// <summary>
+     /// 泛型事件处理器接口
+     /// </summary>
+     /// <typeparam name="TEventData"></typeparam>
+      public interface IEventHandler<TEventData> : IEventHandler where TEventData : IEventData
+      {
+            /// <summary>
+            /// 事件处理器实现该方法来处理事件
+            /// </summary>
+            /// <param name="eventData"></param>
+            void HandleEvent(TEventData eventData);
+      }
+     ```
+
+    - 领域事件的发布和订阅
+      - 领域事件的发布可以使用`发布-订阅模式`来实现。比较常见的实现法师就是事件总线
+      - 事件总线实现的要点
+         - 事件总线维护一个事件源与事件处理的映射字典；
+         - 通过单例模式，确保事件总线的唯一入口；
+         - 利用反射或依赖注入完成事件源与事件处理的初始化绑定
+         - 提供统一的事件注册、取消注册和触发接口
+      - 事件总线的接口定义
+       ```
+       public interface IEventBus
+       {
+           void Register < TEventData > (IEventHandler eventHandler);
+
+            void UnRegister < TEventData > (Type handlerType) where TEventData: IEventData;
+
+             void Trigger < TEventData > (Type eventHandlerType, TEventData eventData) where TEventData: IEventData;
+
+       }
+       在应用服务和领域服务中，我们都可以直接调用Register方法来完成领域事件的注册，调用Trigger方法来完成领域事件的发布。
+
+       ```
+- 最终一致性
+   -  务一致性是是数据库事务的四个特性之一，也就是ACID特性之一：
+   -  原子性（Atomicity）：事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行。
+   -  一致性（Consistency）：事务应确保数据库的状态从一个一致状态转变为另一个一致状态。
+   -  隔离性（Isolation）：多个事务并发执行时，一个事务的执行不应影响其他事务的执行
+   -  持久性（Durability）：已被提交的事务对数据库的修改应该永久保存在数据库中。
+ - 案例 
+   - 订单系统发布"订单成功支付"事件
+   - 库存系统订阅并处理库存扣减逻辑
+   - 通知系统订阅并处理检货通知
+- 事件存储
+   - 事件发布可用于重新发布
+   - 通过消息中间件去分布事件
+   - 事件溯源
+
+
+
+> 聚合
+- 在DDD中，聚合也可以用来表示整体与部分的关系。领域对象的显示分组（订单+订单项）
+   - 封装业务
+   - 保证聚合内领域对象的数据一致性
+
+- 关键
+  - 领域对象间的关联关系 
+    - 基于业务用例而非现实生活建立必要关联
+    - 减少不必要的关联
+    - 将双向关联转换为单项关联
+- 聚合是领域对象的显式分组，旨在支持领域模型的行为和不变性，同时充当一致性和事务性边界。
+  - 领域对象的显式分组
+  - 领域行为和不变性
+  - 一致性和事务性边界
+
+- 一致性边界
+  - 实例：订单支付成功后，订单状态要更新为已支付状态，且现有库存要根据订单中商品实际销售数量进行扣减。
+  - 事务一致性
+  - 最终一致性：实现原理是借助领域事件来完成事务的拆分
+
+
+
+
+> 工厂
+
+- DDD中工厂的主要目标是隐藏对象的复杂创建逻辑;次要目标就是要清楚的表达对象实例化的意图。
+- 工厂模式的实现四种方式
+  - 简单工厂：简单实用，但违反开放封闭
+  - 工厂方法：开放封闭，单一产品
+  - 抽象工厂：开放封闭，多个产品
+  - 反射工厂：可以最大限度的解耦
+
+- 封装内部结构
+
+  - 以添加商品到购物车为例。 步骤 1、 加载用户购物车 2、获取商品税率 3、创建新的购物车子项
+```
+  相关应用层代码
+  public class AddProductToBasket {
+      public void Add (Product product, Guid basketId) {
+        public void Add (Product product, Guid basketId) {
+            var basket = _basketRepository.FindBy (basketId);
+            basket.Add (product);
+      }
+
+  }
+  public class Basket {
+      public void Add (Product product) {
+            if (Contains (product))
+                GetItemFor (product).IncreaseItemQuantitBy (1);
+            else {
+                var rate = TaxRateService.ObtainTaxRateFor (product.Id,
+                    country.Id);
+                var item = new BasketItem (rate, product.Id, product.price);
+                _items.Add (item);
+  }
+```
+
+ ```
+   引入一个工厂对象来封装购物车子项的创建，包括获取正确的税率
+ namespace DomainModel {
+    public class Basket {
+        // ......
+        public void Add (Product product) {
+            if (Contains (product))
+                GetItemFor (product).IncreaseItemQuantitBy (1);
+            else
+                _items.Add (BasketItemFactory.CreateItemFor (product,
+                    deliveryAddress));
+        }
+    }
+    public class BasketItemFactory {
+        public static void CreateBasketFrom (Product product, Country country) {
+            var rate = TaxRateService.ObtainTaxRateFor (product.Id, country.Id);
+            return new BasketItem (rate, product.Id, product.price);
+        }
+    }
+ }
+ 引入工厂模式后，购物车的职责单一了，且隔离了来自购物车子项的变化，比如当税率变化时，或购物车子项需要其他信息创建时，都不会影响到购物车的相关逻辑。
+```
+
+- 还用工厂的好处
+ - 工厂将领域对象的使用和创建分离。
+ - 通过使用工厂类，可以隐藏创建复杂领域对象的业务逻辑。
+ - 工厂类可以根据调用者的需要，创建相应的领域对象。
+ - 工厂方法可以封装聚合的内部状态。
+
+
+> 仓储
+- 特性 ：仓储用来存储和删除聚合，但同时提供针对聚合的显式查询以及汇总。
+  - 存储集合
+  - 删除集合
+- 仓储与数据访问层的区别
+  - 仓储限定了只能通过聚合根来持久化和检索领域对象，以确保所有改动和不变性由聚合处理。
+  - 仓储通过隐藏聚合持久化和检索的底层技术实现领域层的的持久化无关性（即领域层不需要知道如何持久化领域对象）。
+  - 仓储在数据模型和领域模型定义了一个边界。
+
+- 仓储举例
+ ```
+ 简单的仓储定义
+  public interface ICustomerRepository
+  {
+      Customer FindBy(Guid id);
+      void Add(Customer customer);
+      void Remove(Customer customer); 
+  }
+ ```
+
+- 仓储的要点
+  - 是保持你的领域模型和技术持久化框架的独立性，这样你的领域模型可以隔离来自底层持久化技术的影响。如果没有仓储这一层，你的持久化基础设施可能会泄露到领域模型中，并影响领域模型完整性和最终一致性
+
+
+- 仓储方法需要明确
+仓储是原则上是领域模型与持久化存储之间明确的契约，仓储定义的接口方法不仅仅是CURD方法。它是领域模型的扩展，并以领域专家所理解的术语编写。仓储接口的定义应该根据应用程序的用例需求来创建，而不是从类似CURD的数据访问角度来构建。
+
+- 泛型仓储
+  - 举例
+  ```
+  namespace DomainModel {
+    public interface IRepository<T> where T : EntityBase {
+        T GetById (int id);
+        IEnumerable<T> List ();
+        IEnumerable<T> List (Expression<Func<T, bool>> predicate);
+        void Add (T entity);
+        void Delete (T entity);
+        void Edit (T entity);
+    }
+
+    public abstract class EntityBase {
+        public int Id { get; protected set; }
+    }
+   } 
+
+   泛型仓储实现
+   namespace Infrastructure.Persistence {
+    public class Repository<T> : IRepository<T> where T : EntityBase {
+        private readonly ApplicationDbContext _dbContext;
+        public Repository (ApplicationDbContext dbContext) {
+            _dbContext = dbContext;
+        }
+        public virtual T GetById (int id) {
+            return _dbContext.Set<T> ().Find (id);
+        }
+
+        public virtual IEnumerable<T> List () {
+            return _dbContext.Set<T> ().AsEnumerable ();
+        }
+
+        public virtual IEnumerable<T> List (Expression<Func<T, bool>> predicate) {
+            return _dbContext.Set<T> ()
+                .Where (predicate)
+                .AsEnumerable ();
+        }
+
+        public void Insert (T entity) {
+            _dbContext.Set<T> ().Add (entity);
+            _dbContext.SaveChanges ();
+        }
+
+        public void Update (T entity) {
+            _dbContext.Entry (entity).State = EntityState.Modified;
+            _dbContext.SaveChanges ();
+        }
+
+        public void Delete (T entity) {
+            _dbContext.Set<T> ().Remove (entity);
+            _dbContext.SaveChanges ();
+        }
+    }
+  }
+  ```
+  
+- 总结
+  - 仓储作为领域模型和数据模型的中介，它负责映射领域模型到持久化存储。
+  - 仓储实现了透明持久化，即领域层不需要关注领域对象如何持久化。
+  - 仓储是一个契约，而不是数据访问层。它明确表明聚合所必需的数据操作。
+  - ORM框架不是仓储。仓储是一种架构模式。ORM用来以面向对象的方式来表示数据模型。仓储使用ORM来协调领域模型和数据模型。
+  - 仓储适用于具有丰富领域模型的限界上下文。对于没有复杂业务逻辑的简单限界上下文，直接使用持久化框架即可。
+  - 使用UOW进行事务管理。UOW负责跟踪对象的状态，仓储在UOW协调的事务中进行实际的持久化工作。
+  - 仓储用于管理单个聚合，它不应该控制事务。
+
+
+
+> 模块
+
+- 模块的用途也是如此，通过分解领域模型为不同的模块，以降低领域模型的复杂性，提高领域模型的可读性。
+- 模块的设计是基于领域模型的，要符合通用语言的表述。其次，模块的设计要符合高内聚低耦合的设计思想。
+- 模块设计的原则
+  - 根据领域来组织模块
+  - 基于通用语言
+  - 高内聚低耦合
+- 总结
+  - 模块是对领域模型进行分解后的产物，是相对独立的功能单元，由一系列高内聚的领域对象组成，相对聚合、实体和值对象来说是更高一层的抽象。
+  - 模块化的思想大大简化了领域模型的复杂性，即便于我们设计出高内聚低耦合的系统，也便于我们理解系统的设计。

实践/后端/项目/26.DDD微服务.md

@@ -0,0 +1,50 @@
+> DDD分层架构视图
+
+- DDD分层架构包括：展现层、应用层、领域层和基础层
+  - 展现层（Interface）：用户界面 Web服务 其他 =（数据传输）=》应用层
+  - 应用层（Application）：应用层服务
+  - 领域层（Domain）：实体、值对象 领域层服务
+  - 基础实施层（Infrastructure）：数据库、总线、API网关、缓存
+
+> DDD分层架构各层智能
+  
+- 展现层： 负责向用户显示信息和解释用户指令
+- 应用层：主要面向用户用例操作，协调和指挥领域对象来完成业务逻辑。
+    - 应用层也是与其他系统的应用层进行交互的必要渠道。应用服务尽量简单，它不包含业务规则或知识，只为下一层的领域对象协调任务，使它们互相协作。
+    - 应用层还可进行安全认证、权限校验、分布式和持久化事务控制或向外部应用发送基于事件的消息等
+ - 领域层
+    - 领域层是软件的核心所在，它实现全部业务逻辑并且通过各种校验手段保证业务正确性。它包含业务所涉及的领域对象（实体、值对象）、领域服务以及它们之间的关系。它负责表达业务概念、业务状态以及业务规则，具体表现形式就是领域模型
+- 基础层
+    - 基础层为各层提供通用的技术能力，包括：为应用层传递消息、提供 API 管理，为领域层提供数据库持久化机制等。它还能通过技术框架来支持各层之间的交互。
+    
+
+
+> 服务视图
+- 接口服务
+   - 接口服务位于用户接口层，用于处理用户发送的 Restful 请求和解析用户输入的配置文件等，并将信息传递给应用层。
+
+- 应用服务
+   - 应用服务位于应用层。用来表述应用和用户行为，负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装。 应用层的服务包括应用服务和领域事件相关服务。 
+   - 应用服务可对微服务内的领域服务以及微服务外的应用服务进行组合和编排，或者对基础层如文件、缓存等数据直接操作形成应用服务，对外提供粗粒度的服务。 领域事件服务包括两类：领域事件的发布和订阅。通过事件总线和消息队列实现异步数据传输，实现微服务之间的解耦。
+
+- 领域服务
+   - 领域服务位于领域层，为完成领域中跨实体或值对象的操作转换而封装的服务，领域服务以与实体和值对象相同的方式参与实施过程。
+   - 领域服务对同一个实体的一个或多个方法进行组合和封装，或对多个不同实体的操作进行组合或编排，对外暴露成领域服务。
+   - 领域服务封装了核心的业务逻辑。实体自身的行为在实体类内部实现，向上封装成领域服务暴露。 为隐藏领域层的业务逻辑实现，所有领域方法和服务等均须通过领域服务对外暴露。 为实现微服务内聚合之间的解耦，原则上禁止跨聚合的领域服务调用和跨聚合的数据相互关联。
+
+- 基础服务
+   - 基础服务位于基础层。为各层提供资源服务（如数据库、缓存等），实现各层的解耦，降低外部资源变化对业务逻辑的影响。 
+   - 基础服务主要为仓储服务，通过依赖反转的方式为各层提供基础资源服务，领域服务和应用服务调用仓储服务接口，利用仓储实现持久化数据对象或直接访问基础资源。
+
+
+> DDD名词和术语
+
+- Event Storming（事件风暴）：事件风暴是一项团队活动，旨在通过领域事件识别出聚合根，进而划分微服务的限界上下文。在活动中，团队先通过头脑风暴的形式罗列出领域中所有的领域事件，整合之后形成最终的领域事件集合，然后对于每一个事件，标注出导致该事件的命令（Command），再然后为每个事件标注出命令发起方的角色，命令可以是用户发起，也可以是第三方系统调用或者是定时器触发等。最后对事件进行分类整理出聚合根以及限界上下文。
+- Entity（实体）：每个实体是唯一的，并且可以相当长的一段时间内持续地变化。我们可以对实体做多次修改，故一个实体对象可能和它先前的状态大不相同。但是，由于它们拥有相同的身份标识，他们依然是同一个实体。例如一件商品在电商商品上下文中是一个实体，通过商品中台唯一的商品 id 来标示这个实体。
+- ValueObject（值对象）：值对象用于度量和描述事物，当你只关心某个对象的属性时，该对象便可作为一个值对象。实体与值对象的区别在于唯一的身份标识和可变性。当一个对象用于描述一个事物，但是又没有唯一标示，那么它就是一个值对象。例如商品中的商品类别，类别就没有一个唯一标识，通过图书、服装等这些值就能明确表示这个商品类别。
+- Aggregate（聚合）：聚合是实体的升级，是由一组与生俱来就密切相关实体和值对象组合而成的，整个组合的最上层实体就是聚合。
+- Bounded Context（限界上下文）：用来封装通用语言和领域对象，为领域提供上下文语境，保证在领域之内的一些术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性。使团队所有成员能够明确地知道什么必须保持一致，什么必须独立开发。
+
+
+- 代码示例链接 https://github.com/marcinstelmach/Ecommerce.Api.git
+  - 是关于电子商务的API。可用于许多在线商店。

实践/后端/项目/27.DDD事件风暴.md

@@ -0,0 +1,103 @@
+> 为什么采用DDD领域驱动？
+
+- 一句话来说就是解耦，便于扩展。领域驱动也是目前正流行的微服务的前提条件之一。
+> 2019年的智能照明版属于DDD领域驱动吗？
+
+- 2019年的智能照明版中包含了一些DDD的设计思想。比如洋葱头式由内而外的分层；比如用到了MediatR, 是中介者模式的体现，里面包含了Command和对应的Handler；比如CQRS的思想......这些都是DDD的重要思想。但是，2019年的这个版本并没有实践出DDD的精髓。在DDD的设计中，领域模型必须具有松耦合、原子性的特点。所谓的松耦合是指领域实体之间的关系。在2019年的这个版本中是强耦合，领域实体基本上和数据库表是一一对应关系，表和表之间存在外键约束。当系统不断扩展的时候，这种强关系会让领域关系变得纠缠不清。另外，在涉及多表操作的时候，2019年的这个版本有时会通过事务来处理，即通过代码维护领域关系。而真正的DDD会把事务内嵌在Aggregate中。所谓Aggregate有且只有一个聚合根Aggregate Root。
+
+- 洋葱头式由内而外的分层：
+  -  核心层是与领域或技术无关的基础构件块，它包含一些通用的构件块。
+  - 领域层（Domain）是业务逻辑的地方，每个类的方法都是按照领域通用语言中的概念进行命名
+  - API层是领域层的入口，它使用领域中的术语和对象
+  - 基础架构（Infrastructure）层是最外部的一层，它包含了对接各种技术的适配器，例如数据库、用户界面以及外部服务。
+
+- CQRS的思想：CQRS，全称Command Query Responsibility Segregation。直译过来就是命令查询的职责分离。
+  - Command指的是增加/更新数据的处理。
+  - Query指的是查询数据的处理。它不会造成数据的变更
+
+> Aggregate 
+
+- 是一种模式，在代码中实现的具体形式很简单
+  -  定义一个Entity，作为Aggregate Root，称之为聚合根
+  - 遵循Aggregate的完整性规则对领域数据进行操作
+
+- Aggregate的完整性规则
+  - 所有的代码只能通过 Aggregate Root，即聚合根这个特殊的 Entity 访问系统的 Entity，而不能随便的操作任一的 Entity。
+  - 每个事务范围只能更新一个 Aggregate Root 及它所关联的 Entity 状态。
+
+  
+> Event Storming
+- 我们听说过"头脑风暴"，大致是让团队成员一起参与讨论出主意。在DDD中，Event Storming，事件风暴，是让领域专家(熟悉业务的人)、技术人员、产品经理等齐聚一堂，用大家都可以理解的形式表达业务逻辑。通常来说，会在一个比较空的房间内腾出一面墙，大家把想法通过便签贴到墙上。
+
+- 举一个例子：假设用户在某个系统中发布信息，Event Storming中的关键要素大致包括：
+  - Event：触发领域状态改变的动作。比如这里叫，NewsPublished
+  - Aggregate：这里的消息就是领域实体。比如这里叫，News
+  - Command: 所有领域状态的改变，肯定是用户通过系统界面发出的，用户从界面发出的指令叫Command(还记得MediatR中的xxxCommand:IRequest<T>, xxxCommandHandler<TResult, T>吗？这里的IRequest接口就代表着用户发出的Command,每个Command都有响应的Handler)
+  - User：操作系统的用户或角色
+  - Information：用户发出Command信息需要基本的前提信息
+
+
+- 如果我们能清晰地知道Command, Command所需要的Information, 是哪个用户或角色执行Command, 对那个Aggregate执行Command, 以及Event是什么，那基本上所有相关人员对系统的业务逻辑已经做了比较清晰的、统一的描述。
+
+# 用ProcessOn报警写报警版的Event Storming
+  - 报警相关的发生在Warning Aggregate上。Aggregate用浅黄色表示
+  - 事件（Event）用橙色表示 。事件的一般形式为：Aggregate+动词过去式
+  - Command, 浅蓝色，一般形式为：动词+Aggregate
+  - 备注用紫色表示
+  -  用浅绿色来表示读模型。与 CQRS 的 Query 含义相同
+
+- 根据APP界面，报警被创建后，用户申请维修，这时系统会查询用户的报警套餐(User Pacakge), 这里又出来一个User Package的Aggregate，而且由于是查询，返回的是Read Model(一般用绿色), Read Model交给界面
+- 这个界面上有两种可能，一个是用户套餐中的免费维修次数还有，另一个是免费维修次数用完了。如果还有维修次数，用户确认。如果没有维修次数，用户查询所有套餐(Packages)，再次Read Model和界面。
+
+> 报警首页
+
+>报警相关
+- 系统->Create Warning(Command)->Warning(Aggregate)->Warning Created(Event)->当前报警
+- 用户->ApplyFix(Command)->Warning(Aggregate)
+- 系统->Query User Package(Command)->User Package(Aggregate)->User Package Read Model
+  - 根据APP界面，报警被创建后，用户申请维修，这时系统会查询用户的报警套餐(User Pacakge), 这里又出来一个User Package的Aggregate，而且由于是查询，返回的是Read Model(一般用绿色), Read Model交给界面
+- 用户->Query Pakages(command)->Packages(Aggregate)->Packages Read Model
+  - 这个界面上有两种可能，一个是用户套餐中的免费维修次数还有，另一个是免费维修次数用完了。如果还有维修次数，用户确认。如果没有维修次数，用户查询所有套餐(Packages)，再次Read Model和界面。
+- 用户-> Confirm Apply Fix(Command)->Warning (Aggregate)->Warning Apply Fix Confirmed(Event)
+- 客服->Dispatch Warning(Command)->Warning(Aggregate)->Warning Dispatched(Event)
+- 电工-> Accept Warning（command）->Warning->Warning Accepted(Event)
+- 电工-> Confirm Warning Repair->Warning->Warning Repair Confirmed(Event)
+- 系统->Finish Warning->Warning ->Warning Finished(Event)
+
+# 开关管理
+> 位置分类相关
+- 安装人员-> Create Electric Box(Command)->Electric Box(Aggregate)->Electric Box Creted 
+- 安装人员-> Create Category(Command)->Category用途(Aggregate)->Category Creted 
+- 安装人员-> Create Line Type(Command)->Line Type开关类型(Aggregate)->Category Line Type
+- 安装人员->  Add Mac To Electric Box(Command)->Mac(Aggregate)->Mac Added To Electric Box(Event)
+- 安装人员->  Add Line To Category(Command)->Line线路（Aggregate)->Lined Added To Category(Event)
+- 安装人员->  Add Line To Line Type(Command)->Line线路（Aggregate)->Lined Added To Line Type(Event)
+- 安装人员->  set Line (Command)->Line线路（Aggregate)->Line Set(Event)
+
+> 场景
+- 安装人员+用户 TimingInfo+LineInfo（Read model）->Create Scene(Command)->SCene(Aggregate)->Scene Created(Event)
+
+
+> 电费和套餐
+
+- 管理员->Set User Package->User Package->User Package set
+- 管理员->Set User Electricity Type-> User Electricity Type-> User Electricity Type set
+- 管理员-> Set Fixed Electricity->User Fixed Electricity->User Fixed Electricity Set
+- 管理Set High Low Electricity ->User High Low Electricity->User High Low Electricity Set
+- 管理员-> Set Step Electricity->User Step Electricity->User Step Electricity Set
+
+
+
+
+
+
+> 领域设计
+- 所有的领域应该有一个抽象基类，而且是一个泛型类。
+```
+public abstract class Entity<T>
+{
+  public T Id{get;protect set;}
+
+}
+```
+-  DDD中有一个很重要的概念 ，叫做Object Value（值对象）。会把一个Aggregate里的对象类型看作是值类型。这样做一方面是减少Aggregate对关系的依赖，一方面可以很好判断Aggregage的状态。同样也是一个泛型抽象基类，如果一个Object类型的对象想要被当作值类型处理，那就继承这个泛型抽象基类。

实践/后端/项目/imgs/28.领域设计.md

@@ -0,0 +1,178 @@
+> 领域设计
+
+- 所有的领域应该有一个抽象基类，而且是一个泛型
+```
+public abstract class Entity<T>
+{
+    public T Id{get;protected set;}
+}
+```
+
+- DDD中有一个很重要的概念，叫作Object Value Type。会把一个Aggregate里的对象类型看作是值类型。这样做一方面是减少Aggregate对关系的依赖，一方面可以很好判断Aggregage的状态。同样也是一个泛型抽象基类，如果一个Object类型的对象想要被当作值类型处理，那就继承这个泛型抽象基类。
+- object value type怎么理解
+  - 值对象 主要描述领域的某个方面而本身没有概念表示的对象。
+  - 主要是为了方便比较领域对象。
+    - 以前
+    ```
+    public class Order
+    {
+        public List<OrderLine> Lines{get;set;}
+        public Address Address{get;set;}
+    }
+    ```
+    - 实际上Order里面包含了对象类型，是很难比较的
+    - 现在
+    ```
+    public class OrderLine:ValueObject<OrderLine>,
+    public class Address:ValueObject<Address>
+    ```
+    - 这就把原来是引用类型的对象OrderLine和Address转换成值类型了，这就减少了对象之间的相互依赖。
+```
+ public abstract class ValueObject<T> where T : ValueObject<T>
+    {
+        /// <summary>
+        /// 获取子类需要比较的属性
+        /// 抽象方法，通过子类override实现
+        /// </summary>
+        protected abstract IEnumerable<object> GetAttributesToIncludeInEqualityCheck();
+
+        /// <summary>
+        /// 比较
+        /// 可以被子类重写
+        /// </summary>
+        public virtual bool Equals(T other)
+        {
+            if (other == null) return false;
+
+            //两个对象的属性值比较
+            return GetAttributesToIncludeInEqualityCheck().SequenceEqual(other.GetAttributesToIncludeInEqualityCheck());
+        }
+
+        /// <summary>
+        /// 重写object基类的比较大小的方法
+        /// </summary>
+        public override bool Equals(object other)
+        {
+            return Equals(other as T);
+        }
+
+        /// <summary>
+        /// 重写object基类的GetHashCode
+        /// </summary>
+        public override int GetHashCode()
+        {
+            var hash = 17;
+            foreach (var obj in this.GetAttributesToIncludeInEqualityCheck())
+            {
+                hash = hash * 31 + (obj == null ? 0 : obj.GetHashCode());
+            }
+            return hash;
+        }
+
+        /// <summary>
+        /// 重新定义==
+        /// </summary>
+        public static bool operator ==(ValueObject<T> left, ValueObject<T> right)
+        {
+            return Equals(left, right);
+        }
+
+        /// <summary>
+        /// 重新定义=
+        /// </summary>
+
+        public static bool operator !=(ValueObject<T> left, ValueObject<T> right)
+        {
+            return !(left==right);
+        }
+    }
+
+```
+- 以上，ValueObject<T>就是Object Value Type的抽象基类，大致作了如下事情：
+
+   - 重写基类object的Equals方法
+   - 重写基类object的GetHashCode方法
+   - 提供一个抽象方法，让子类根据各自不同的属性比较大小，让子类重写
+   - 有一个自定义的比较大小的方法，会调用基类的抽象方法
+   - 重新定义==和!=
+
+- 所有的领域也好，或者Aggregate也好，都需要事件驱动。关于事件，同样需要一个基类。
+```
+ public abstract class DomainEvent
+    {
+        public Guid Id { get; protected set; }
+        public DateTime OccuredOn { get; protected set; }
+
+        protected DomainEvent(Guid id, DateTime occuredOn)
+        {
+            Id = id;
+            OccuredOn = occuredOn;
+        }
+
+        protected DomainEvent()
+        {
+            Id = Guid.NewGuid();
+            OccuredOn = SysTime.Now();
+        }
+    }
+    以上，DomainEvent就是事件的抽象基类。
+```
+- 一个属性是Guid类型，这是很有特色的一个点，事件居然也有Guid类型，就像很多领域都有主键一样
+- 在DDD中，完全可以实现Event Sourcing，事件追溯。注意，这里的Event Sourcing和前面说的Event Storming不一样。Event Soucing适合的场景包括：银行、保险公司等。对于一个领域来说，只要执行了相同数量、相同顺序的事件，领域就会来到一个确定的状态。据说，前端框架Redux就用到了Event Stroming,让领域的状态可追溯。当然，一般的项目用不上Event Sourcing。
+- 以上，DateTime类型的属性OccurredOn的值是通过一个静态方法获取到的。这样做有什么好处呢？
+```
+public class SysTime
+    {
+        public static Func<DateTime> CurrentTimeProvider { get; set; } = () => DateTime.Now;
+
+        public static DateTime Now() => CurrentTimeProvider();
+    }
+```
+- 以上，Now方法类似方法内的一个工厂方法，产生DateTime的实例。但实例是通过CurrentTimeProvider这个委托得到的。不难理解，通过委托获取DateTime实例增加了灵活性。所谓的委托，就是定义好输入形参和返回类型，委托就是一个方法，把方法看作一个变量，调用委托，就是调用方法。
+
+- 以上，有了领域的基类Entity, 有了Object Value Type, 有了事件的基类。接下来，事件需要被发布，这样系统内都某个事件订阅者能获悉并执行。所以，事件发布需要一个接口：
+```
+ public interface IEventPublisher
+    {
+        void Publish(DomainEvent @event);
+    }
+```
+- 以上，所有的要么是抽象基类，要么是接口，我们可以体会到：在领域层基本都是抽象的。也就是在我们所熟悉的洋葱架构中，越内层的越抽象，越外层越具体，越抽象也意味着更低的耦合性、更好的扩展性。而且，领域层，乃至领域层的外面一层都是抽象居多，这一点也方便单元测试。
+
+
+
+- 接下来，会把Event Storming中的设计拿来，考虑如何定义领域
+- 首先，所有的领域都会有主键，通常使用Guid类型，但是Guid类型是一个Object类型，这在DDD的领域设计中需要把之转换成值类型，也就是Object Value Type。
+```
+public class EntityId : ValueObject<EntityId>
+    {
+        protected override IEnumerable<object> GetAttributesToIncludeInEqualityCheck()
+        {
+            yield return Value;
+        }
+
+        public Guid Value { get; }
+
+        public EntityId(Guid value)
+        {
+            Value = value;
+        }
+
+        protected EntityId() { }
+    }
+
+```
+- 以上，EntityId就是Object Value Type，派生于ValueObject<T>。GetAttributesToIncludeInEqualityCheck方法是重写或者说实现基类的方法，当ValueObject的Equals方法的时候会调用GetAttributesToIncludeInEqualityCheck方法。EntityId有一个比较奇怪的地方，就是有个无参的构造函数，这个是为EF Core准备的。
+
+
+- 接着，创建第一个领域或者说Aggregate:
+```
+ /// <summary>
+    /// 报警
+    /// </summary>
+    public class Warning : Entity<EntityId>
+    {
+    }
+```
+- 以上，Warning派生于领域抽象基类Entity<T>,这里的T表示领域的主键类型，这里的主键类型是EntityId,也就是Object Value Type, 可以看作是一个像int类型那样的值类型。
+