DDD~领域事件应用篇(订单处理变得更清晰)

回到目录

上一讲主要说了领域事件和领域总线，这并不是一个很容易理解的文章，所以本讲实例篇主要是为了补充上一讲的理论知识，本讲实例关注的是实际中的订单处理模块，我们知道，订单处理是电子商务的核心，往往在这里面，会有很多逻辑，在开发时，给我们带来了不少的难度，如何更好的分离关注点，是本讲的主题；本讲主要是修改订单状态后，为用户发通知为例，来以此更好的说一下领域事件在实际中的作用。

前言　领域事件使用的设计模式是发布/订阅模式，或者叫观察者模式。

一　订单的几种状态，在订单进入到其中一些状态时，需要通知用户

　　public enum OrderStatus
    {
        /// <summary>
        /// 表示销售订单的已创建状态 - 表明销售订单已被创建（未用）。
        /// </summary>
        [Description("用户下单")]
        Created = 0,
        /// <summary>
        /// 订单被用户取消
        /// </summary>
        [Description("取消订单")]
        Canceled,
        /// <summary>
        /// 表示销售订单的已付款状态 - 表明客户已向销售订单付款。
        /// </summary>
        [Description("用户付款")]
        Paid,
        /// <summary>
        /// 表示销售订单的已发货状态。
        /// </summary>
        [Description("已经发货")]
        Dispatched,
        /// <summary>
        /// 订单已经完成
        /// </summary>
        [Description("订单完成")]
        Finished,

    }

二　为需要通知的状态，创建领域事件数据源(原来在.net事件里，它一般是EventArgs对象)

    /// <summary>
    /// 订单已经确认事件源
    /// </summary>
    public class Order_Confirm_Event : Project.Events.EventBase
    {
        public int OrderId { get; set; }
        public string UserName { get; set; }
    }
    /// <summary>
    /// 订单已经付款事件缘
    /// </summary>
    public class Order_Paid_Event : Project.Events.EventBase
    {
        public int OrderId { get; set; }
        public string UserName { get; set; }
        public decimal TotalPrice { get; set; }
    }
    /// <summary>
    /// 订单已经发货事件源
    /// </summary>
    public class Order_Dispatch_Event : Project.Events.EventBase
    {
        public int OrderId { get; set; }
        public string UserName { get; set; }
    }

三　为这些事件源添加事件处理方式

我们一般理解为“行为”，一种事件源可以有多种事件行为，如一个订单付款事件源，它可以同时有电子邮件行为和短信行为；反之，一个事件处理方式也可以对应多个事件源，如一个电子邮件行为，它可以同时对应订单付款

和订单发货等事件源，所以，领域事件在项目中是非常灵活的。

   　/// <summary>
    /// 发Email的事件处理方式
    /// 调用方法：EventBus.Instance.Subscribe<User_Depts_Event>(new SendEmailEventHandler())
    ///　　　　　 EventBus.Instance.Subscribe<User_Roles_Event>(new SendEmailEventHandler())
    /// </summary>
    public class SendEmail_EventHandler :
       IEventHandler<Order_Confirm_Event>,
        IEventHandler<Order_Dispatch_Event>,
        IEventHandler<Order_Paid_Event>
    {
        static string prefix = "本消息来自电子邮件";

        #region IEventHandler<Order_Confirm_Event> 成员

        public void Handle(Order_Confirm_Event evt)
        {
            Logger.Core.LoggerFactory.Instance.Logger_Info(string.Format("尊敬的客户{0}，你的订单已经确认，订单号{1}，请尽快付款！({2})[{3}]"
                , evt.UserName
                , evt.OrderId
                , evt.EventDate
                , prefix));
        }

        #endregion

        #region IEventHandler<Order_Dispatch_Event> 成员

        public void Handle(Order_Dispatch_Event evt)
        {
            Logger.Core.LoggerFactory.Instance.Logger_Info(string.Format("尊敬的客户{0}，你的订单已经发货，订单号{1}，请注意查收！({2})[{3}]"
                , evt.UserName
                , evt.OrderId
                , evt.EventDate
                , prefix));

        }

        #endregion

        #region IEventHandler<Order_Paid_Event> 成员

        public void Handle(Order_Paid_Event evt)
        {
            Logger.Core.LoggerFactory.Instance.Logger_Info(string.Format("尊敬的客户{0}，你的订单已经成功付款，订单号{1}，付款金额为{2}元，我们会尽快安排发货！({3})[{4}]"
                 , evt.UserName
                 , evt.OrderId
                 , evt.TotalPrice
                 , evt.EventDate
                 , prefix));
        }

        #endregion
    }
    /// <summary>
    /// 发短信的事件处理方式
    /// </summary>
    public class SendSMS_EventHandler :
         IEventHandler<Order_Confirm_Event>,
         IEventHandler<Order_Dispatch_Event>,
         IEventHandler<Order_Paid_Event>
    {
        static string prefix = "本消息来自短信";

        #region IEventHandler<Order_Confirm_Event> 成员

        public void Handle(Order_Confirm_Event evt)
        {
            Logger.Core.LoggerFactory.Instance.Logger_Info(string.Format("尊敬的客户{0}，你的订单已经确认，订单号{1}，请尽快付款！({2})[{3}]"
                , evt.UserName
                , evt.OrderId
                , evt.EventDate
                , prefix));
        }

        #endregion

        #region IEventHandler<Order_Dispatch_Event> 成员

        public void Handle(Order_Dispatch_Event evt)
        {
            Logger.Core.LoggerFactory.Instance.Logger_Info(string.Format("尊敬的客户{0}，你的订单已经发货，订单号{1}，请注意查收！({2})[{3}]"
                , evt.UserName
                , evt.OrderId
                , evt.EventDate
                , prefix));

        }

        #endregion

        #region IEventHandler<Order_Paid_Event> 成员

        public void Handle(Order_Paid_Event evt)
        {
            Logger.Core.LoggerFactory.Instance.Logger_Info(string.Format("尊敬的客户{0}，你的订单已经成功付款，订单号{1}，付款金额为{2}元，我们会尽快安排发货！({3})[{4}]"
                 , evt.UserName
                 , evt.OrderId
                 , evt.TotalPrice
                 , evt.EventDate
                 , prefix));
        }

        #endregion
    }

四　订阅领域事件

我们需要有一个入口来订阅领域事件，如订阅订单确认事件，订单付款事件等，简单的做法是在global里统一注册，而标准合理的作法，我觉得应该在订单controller的静态构造方法里去注册它，因为只有用户操作订单相关模块时，才可能触

发订单这些事件！

　　　　 /// <summary>
        /// 类的构造方法，处理与具体实例无法的东西
        /// </summary>
        static OrderController()
        {
            #region 订阅相关领域事件

            #region 订阅发email处理方式
            EventBus.Instance.Subscribe<Order_Confirm_Event>(new SendEmail_EventHandler());
            EventBus.Instance.Subscribe<Order_Dispatch_Event>(new SendEmail_EventHandler());
            EventBus.Instance.Subscribe<Order_Paid_Event>(new SendEmail_EventHandler());
            #endregion

            #region 订阅发短信的处理方式
            EventBus.Instance.Subscribe<Order_Confirm_Event>(new SendSMS_EventHandler());
            EventBus.Instance.Subscribe<Order_Dispatch_Event>(new SendSMS_EventHandler());
            EventBus.Instance.Subscribe<Order_Paid_Event>(new SendSMS_EventHandler());
            #endregion

            #endregion
        }

我们看到了，每种订单事件源都被注册了电子邮件和短信两种事件处理方式，这在对应的事件被触发（发布，publish)之后，它们会被执行。

六　触发具体事件

具体的事件在具体的方法里，独立的去触发，一般它会在业务逻辑层完成

　　　　 /// <summary>
        /// 用户下单:create
        /// </summary>
        /// <param name="entity"></param>
        public void DoOrder(Order_Info entity)
        {
            entity.OrderStatus = (int)OrderStatus.Created;
            _orderRepository.Insert(entity);
            entity.Order_Detail.ToList().ForEach(j => j.OrderId = entity.Id);
            _orderDetailRepository.Insert(entity.Order_Detail);
            EventBus.Instance.Publish(new Order_Confirm_Event { OrderId = entity.Id, UserName = entity.UserName });
        }

        /// <summary>
        /// 订单付款:paid
        /// </summary>
        /// <param name="entity"></param>
        public void PaidOrder(Order_Info entity)
        {
            entity.OrderStatus = (int)OrderStatus.Paid;
            _orderRepository.Update(entity);
            EventBus.Instance.Publish(new Order_Paid_Event { OrderId = entity.Id, TotalPrice = entity.TotalPrice, UserName = entity.UserName });
        }

        /// <summary>
        /// 订单发货:dispatch
        /// </summary>
        /// <param name="entity"></param>
        public void DispatchOrder(Order_Info entity)
        {
            entity.OrderStatus = (int)OrderStatus.Dispatched;
            _orderRepository.Update(entity);
            EventBus.Instance.Publish(new Order_Dispatch_Event { OrderId = entity.Id, UserName = entity.UserName });
        }

八　最后，我们看一下处理处理页面和结果的截图

生成的日志

生成的日志内容，类似于用户上到的电子邮件或者短信的内容

怎么样，看完这个例子相信您对领域事件有了更清晰的认识了吧，呵呵！

回到目录

时间： 2024-11-01 11:05:23

DDD~领域事件应用篇(订单处理变得更清晰)的相关文章

DDD领域事件与事件总线源码下载

最近在看领域事件的文章.看到了“张占岭”的<DDD~领域事件与事件总线> 原文地址:http://www.cnblogs.com/lori/p/3476703.html 遗憾的是没有提供下载,把文中的代码复制下来但发现不完整.于是决定自己补全代码. 说明:本来只是打算做一次性的测试项目所以没有命名的.其中用XML初始化的代码也被注释了. 下载地址: http://pan.baidu.com/s/1c0DD5eS 梦回周公

由微服务，领域事件，分布式事件谈“业务分析三维度理论”的实践

今天读了在微服务中使用领域事件 这篇文章,通过分布式,订单系统直接将事件推送给订阅此事件的账户系统,然后账户系统再处理,整个系统设计很好. 不过,我觉得所谓微服务的分布式事件,从抽象概念上还是弱了点,不如Actor模型,应该将事件抽象成消息,消息包括命令,事件,或者其它无关紧要的东西.每一个Actor接收场景中的消息,或者产生消息,或者转发消息:消息如何处理,取决于Actor的内置规则. 所以,真实世界的模型是有很多场景,在某个场景中有些Actor,Actor相互交互,发生和改变什么东西.场景中

Lind.DDD.Events领域事件介绍

回到目录 闲话多说 领域事件大叔感觉是最不好讲的一篇文章,所以拖欠了很久,但最终还是在2015年年前(阴历)把这个知识点讲一下,事件这个东西早在C#1.0时代就有了,那时学起来也是一个费劲,什么是委托,哪个是事件,搞的大家是糊里糊涂,进入C#2.0时代后,大叔也买了一本书,对于delegate和event这两个知识点看了至少有20几遍,感觉稍微有点明白了,明白了其中的真谛和用意. 委托:方法的规范,方法的模板,可以代表一类方法的集合 事件:委托的实例,事件在使用之前需要为它赋值,当然赋的就是一个

DDD领域驱动之干货（四）补充篇！

距离上一篇DDD系列完结已经过了很长一段时间,项目也搁置了一段时间,想想还是继续完善下去. DDD领域驱动之干货(三)完结篇! 上一篇说到了如何实现uow配合Repository在autofac和automapper下实现的功能,今天完善一下事件驱动也就是领域驱动. 领域驱动的概念网上一搜一大推,我就不一一累赘,本文主要讲解如何实现领域事件和事件总线. 事件一共提供三个方法去完成事件的实现-----------注册事件.卸载事件.发布事件 那么在注册事件的时候我们怎么样是定义一个事件呢? 如下图

(转载）浅谈我对DDD领域驱动设计的理解

原文地址:http://www.cnblogs.com/netfocus/p/5548025.html 从遇到问题开始 当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品.所以,自然而然就想到要做一个普通电商系统,用于实现在线销售自己企业产品的目的. 再比如,我是一家互联网公司,公司有很多系统对外提供服务,面向很多客户端设备.但是最近由于各种原因,导致服务经常出故

浅谈我对DDD领域驱动设计的理解

从遇到问题开始 当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品.所以,自然而然就想到要做一个普通电商系统,用于实现在线销售自己企业产品的目的. 再比如,我是一家互联网公司,公司有很多系统对外提供服务,面向很多客户端设备.但是最近由于各种原因,导致服务经常出故障.所以,我们希望通过各种措施提高服务的质量和稳定性.其中的一个措施就是希望能做一个灰度发布的平台,这个

学习：DDD领域驱动设计

DDD:Domain-driven Design(领域 - 驱动 -> 设计) ->领域驱动领域模型设计 ->领域模型驱动代码实现 摘自网络(汤雪华的博客) <概念总结> 领域就是问题域,有边界,领域中有很多问题: 任何一个系统要解决的那个大问题都对应一个领域: 通过建立领域模型来解决领域中的核心问题,模型驱动的思想: 领域建模的目标针对我们在领域中所关心的问题,即只针对核心关注点,而不是整个领域中的所有问题: 领域模型在设计时应考虑一定的抽象性.通用性,以及复用价值: 通过

DDD领域驱动设计仓储Repository

DDD领域驱动设计初探(二):仓储Repository(上) 前言:上篇介绍了DDD设计Demo里面的聚合划分以及实体和聚合根的设计,这章继续来说说DDD里面最具争议的话题之一的仓储Repository,为什么Repository会有这么大的争议,博主认为主要原因无非以下两点:一是Repository的真实意图没有理解清楚,导致设计的紊乱,随着项目的横向和纵向扩展,到最后越来越难维护:二是赶时髦的为了“模式”而“模式”,仓储并非适用于所有项目,这就像没有任何一种架构能解决所有的设计难题一样.本篇

C#进阶系列——DDD领域驱动设计初探（二）：仓储Repository（上）

前言:上篇介绍了DDD设计Demo里面的聚合划分以及实体和聚合根的设计,这章继续来说说DDD里面最具争议的话题之一的仓储Repository,为什么Repository会有这么大的争议,博主认为主要原因无非以下两点:一是Repository的真实意图没有理解清楚,导致设计的紊乱,随着项目的横向和纵向扩展,到最后越来越难维护:二是赶时髦的为了“模式”而“模式”,仓储并非适用于所有项目,这就像没有任何一种架构能解决所有的设计难题一样.本篇通过这个设计的Demo来谈谈博主对仓储的理解,有不对的地方还望