DDD+微服务实战：什么是DDD？

Posted 2021-11-12 南北12345678

1 DDD是什么？

DDD是领域驱动设计，是Eric Evans于2003年提出的，离现在有17年。

2 为什么需要DDD

当软件越来越复杂，实际开发中，大量的业务逻辑堆积在一个巨型类中的例子屡见不鲜，代码的复用性和扩展性无法得到保证。为了解决这样的问题，DDD提出了清晰的分层架构和领域对象的概念，让面向对象的分析和设计进入了一个新的阶段，对企业级软件开发起到了巨大的推动作用。

2.1 POP，OOP，DDD是如何解决问题

面向过程编程（POP），接触到需求第一步考虑把需求自顶向下分解成一个一个函数。并且在这个过程中考虑分层，模块化等具体的组织方式，从而分解软件的复杂度。当软件的复杂度不是很大，POP也能得到很好的效果。

面向对象编程（OOP），接触到需求第一步考虑把需求分解成一个一个对象，然后每个对象添加一个一个方法和属性，程序通过各种对象之间的调用以及协作，从而实现计算机软件的功能。跟很多工程方法一样，OOP的初衷就是一种处理软件复杂度的设计方法。

领域驱动设计（DDD），接触到需求第一步考虑把需求分解成一个一个问题域，然后再把每个问题域分解成一个一个对象，程序通过各种问题域之间的调用以及协作，从而实现计算机软件的功能。DDD是解决复杂中大型软件的一套行之有效方式，现已成为主流。

2.2 POP，OOP，DDD的特点

POP，无边界，软件复杂度小适用，例如“盖房子”。

OOP，以“对象”为边界，软件复杂度中适用，例如“盖小区”。

DDD，以“问题域”为边界，软件复杂度大适用，例如“盖城市”。

3 DDD的分层架构和构成要素

3.1 分层架构

整个架构分为四层，其核心就是领域层（Domain），所有的业务逻辑应该在领域层实现，具体描述如下：

用户界面/展现层，负责向用户展现信息以及解释用户命令。

应用层，很薄的一层,用来协调应用的活动。它不包含业务逻辑。它不保留业务对象的状态,但它保有应用任务的进度状态。

领域层，本层包含关于领域的信息。这是业务软件的核心所在。在这里保留业务对象的状态,对业务对象和它们状态的持久化被委托给了基础设施层。

基础设施层，本层作为其他层的支撑库存在。它提供了层间的通信,实现对业务对象的持久化,包含对用户界面层的支撑库等作用。

3.2 构成要素

实体（Entity），具备唯一ID，能够被持久化，具备业务逻辑，对应现实世界业务对象。

值对象（Value Object），不具有唯一ID，由对象的属性描述，一般为内存中的临时对象，可以用来传递参数或对实体进行补充描述。

领域服务（Domain Service），为上层建筑提供可操作的接口，负责对领域对象进行调度和封装，同时可以对外提供各种形式的服务。

聚合根（Aggregate Root），聚合根属于实体对象，聚合根具有全局唯一ID，而实体只有在聚合内部有唯一的本地ID，值对象没有唯一ID

工厂（Factories），主要用来创建聚合根，目前架构实践中一般采用IOC容器来实现工厂的功能。

仓储（Repository），封装了基础设施来提供查询和持久化聚合操作。

4 小结

通过本文介绍，我们了解DDD是为解决软件复杂性而诞生，与OOP最大的区别就是划分边界的方式不一样，所以DDD本身掌握起来并不会感觉复杂，DDD其实是研究将包含业务逻辑的ifelse语句放在哪里的学问。

 

微服务实战：落地微服务架构到直销系统(构建消息总线框架接口)

从上一篇文章大家可以看出，实现一个自己的消息总线框架是非常重要的内容，消息总线可以将界限上下文之间进行解耦，也可以为大并发访问提供必要的支持。

消息总线的作用：

1.界限上下文解耦：在DDD第一波文章中，当更新了订单信息后，我们通过调用经销商界限上下文的领域模型和仓储，进行了经销商信息的更新，这造成了耦合。通过一个消息总线，可以在订单界限上下文的WebApi服务(来源微服务-生产者)更新了订单信息后，发布一个事件消息到消息总线的某个队列中，经销商界限上下文的WebApi服务(消费者)订阅这个事件消息，然后交给自己的Handler进行消息处理，更新自己的经销商信息。这样就实现了订单界限上下文与经销商界限上下文解耦。

2.大并发支持：可以通过消息总线进一步提升下单的性能。我们可以将用户下单的操作直接交给一个下单命令WebApi接收，下单命令WebApi接收到命令后，直接丢给一个消息总线的队列，然后立即给前端返回下单结果。这样用户就不用等待后续的复杂订单业务逻辑，加快速度。后续订单的一系列处理交给消息的Handler进行后续的处理与消息的进一步投递。

 

消息总线设计重点：

1.定义消息(事件)的接口：所有需要投递与处理的消息，都从这个消息接口继承，因为需要约束消息中必须包含的内容，比如消息的ID、消息产生的时间等。

public interface IEvent
    {
        Guid Id { get; set; }
        DateTime CreateDate { get; set; }
    }

2.定义消息(事件)处理器接口：当消息投递到消息总线队列中后，一定有消费者WebApi接收并处理这个消息，具体的处理方法逻辑在订阅方处理器中实现，这里先需要定义处理器的接口，便于在消息总线框架中使用。

public interface IEventHandler
    {
        Task<bool> HandleAsync<TEvent>(TEvent @event) where TEvent : IEvent;
    }

从上面代码可以看出，消息(事件)处理器处理的类型就是从IEvent接口继承的消息类。

3.定义消息(事件)与消息(事件)处理器关联接口：一种类型的消息被投递后，一定要在订阅方找到这种消息的处理器进行处理，所以一定要定义二者的关联接口，这样才能将消息与消息处理器对应起来，才能实现消息被订阅后的处理。

 public interface IEventHandlerExecutionContext
    {
        void RegisterEventHandler<TEvent, TEventHandler>() where TEvent : IEvent
            where TEventHandler : IEventHandler;
        bool IsRegisterEventHandler<TEvent, TEventHandler>() where TEvent : IEvent
            where TEventHandler : IEventHandler;
        Task HandleAsync<TEvent>(TEvent @event) where TEvent : IEvent;
    }

RegisterEventHandler方法就是建立消息与消息处理器的关联，这个方法其实是在订阅方使用，订阅方告诉消息总线，什么样的消息应该交给我的哪个处理器进行处理。

IsRegisterEventHandler方法是判断消息与处理器之间是否已经存在关联。

HandleAsync方法是通过查找到消息对应的处理器后，然后调用处理器自己的Handle方法进行消息的处理.

4.定义消息发布、订阅与消息总线接口：消息总线至少要支持两个功能，一个是生产者能够发布消息到我的消息总线，另一个是订阅方需要能够从我这个消息总线订阅消息。

 public interface IEventPublisher
    {
        void Publish<TEvent>(TEvent @event) where TEvent : IEvent;
    }

从上面代码可以看出，生产者发布的消息仍然要从IEvent继承的类型。

 public interface IEventSubscriber
    {
        void Subscribe<TEvent, TEventHandler>() where TEvent : IEvent
            where TEventHandler : IEventHandler;
    }

上面代码是订阅方用于从消息总线订阅消息，从代码中可以看出，它的最终的实现其实就是建立消息与处理器之间的关联。

 public interface IEventBus:IEventPublisher,IEventSubscriber
    {
    }

消息(事件)总线从两个接口继承下来，同时支持消息的发布与消息的订阅。

5.实现事件基类：上面已经订阅了消息(事件)的接口，这里来实现事件的基类，其实就是实现消息ID与产生的时间：

  public class BaseEvent : IEvent
    {
        public Guid Id { get; set; }
        public DateTime CreateDate { get; set; }
        public BaseEvent()
        {
            this.Id = Guid.NewGuid();
            this.CreateDate = DateTime.Now;
        }
    }

6.实现消息总线基类：消息总线底层的依赖可以是各种消息代理产品，比如RabbitMq、Kafaka或第三方云平台提供的消息代理产品，通常我们要封装这些消息代理产品。在封装之前，我们需要定义顶层的消息总线基类实现，主要的目的是未来依赖于它的具体实现可替换，另外也将消息与消息处理器的关联接口传递进来，便于订阅方使用。

public abstract class BaseEventBus : IEventBus
    {
        protected readonly IEventHandlerExecutionContext eventHandlerExecutionContext;
        protected BaseEventBus(IEventHandlerExecutionContext eventHandlerExecutionContext)
        {
            this.eventHandlerExecutionContext = eventHandlerExecutionContext;
        }
        public abstract void Publish<TEvent>(TEvent @event)
            where TEvent : IEvent;
        public abstract void Subscribe<TEvent, TEventHandler>()
            where TEvent : IEvent
            where TEventHandler : IEventHandler;
    }

7.实现消息与处理器关联：消息必须与处理器关联，订阅方收到特定类型的消息后，才知道交给哪个处理器处理。

 public class EventHandlerExecutionContext : IEventHandlerExecutionContext
    {
        private readonly IServiceCollection registry;
        private readonly IServiceProvider serviceprovider;
        private Dictionary<Type, List<Type>> registrations = new Dictionary<Type, List<Type>>();
        public EventHandlerExecutionContext(IServiceCollection registry,Func<IServiceCollection,
            IServiceProvider> serviceProviderFactory = null)
        {
            this.registry = registry;
            this.serviceprovider = this.registry.BuildServiceProvider();
        }

       //查找消息关联的处理器，然后调用处理器的处理方法
        public async Task HandleAsync<TEvent>(TEvent @event) where TEvent : IEvent
        {
            var eventtype = @event.GetType();
            if(registrations.TryGetValue(eventtype,out List<Type> handlertypes) && handlertypes.Count > 0)
            {
                using(var childscope = this.serviceprovider.CreateScope())
                {
                    foreach(var handlertype in handlertypes)
                    {
                        var handler = Activator.CreateInstance(handlertype) as IEventHandler;
                        await handler.HandleAsync(@event);
                    }
                }
            }
        }

       //判断消息与处理器之间是否有关联
        public bool IsRegisterEventHandler<TEvent, TEventHandler>()
            where TEvent : IEvent
            where TEventHandler : IEventHandler
        {
            if(registrations.TryGetValue(typeof(TEvent),out List<Type> handlertypelist))
            {
                return handlertypelist != null && handlertypelist.Contains(typeof(IEventHandler));
            }
            return false;
        }
       
      //将消息与处理器关联起来，可以在内存中建立关联，也可以建立在数据库单独表中
        public void RegisterEventHandler<TEvent, TEventHandler>()
            where TEvent : IEvent
            where TEventHandler : IEventHandler
        {
            Utils.DictionaryRegister(typeof(TEvent), typeof(TEventHandler), registrations);
        }
    }

上面我们基本上就将消息总线的架子搭建起来了，也实现了基本的功能，下一章我们基于它来实现RabbitMq的消息总线。

QQ讨论群：309287205 

微服务实战视频请关注微信公众号：