DDD 领域驱动设计-如何 DDD?

  1. 云栖社区>
  2. 博客>
  3. 正文

DDD 领域驱动设计-如何 DDD?

技术小哥哥 2015-09-24 18:31:00 浏览1178
展开阅读全文

435188-20160414100345254-1897931146.jpg

注:科比今天要退役了,我是 60 亿分之一,满腹怀念~

前几天看了园友的一篇文章《我眼中的领域驱动设计》,文中有段话直击痛点:有人误认为项目架构中加入 Repository,Domain,ValueObject 就变成了 DDD 架构。没错,我就是这样,不过准确的来说,并不能称为 DDD 架构,而是我之前经常说的“伪 DDD”设计,后来我还抽离出了一个伪 DDD 设计框架:DDD.Sample,大家有兴趣的可以瞧瞧,在实际项目的开发中,我用它做过了几个不太大的项目,我个人觉得用起来很顺手,当然并没有真正的 DDD 设计,只不过用了一个空的架构而已,然后冠以”DDD 开发“的名号。

因为之前有过 DDD 设计的痛苦经历(短消息系统),具体表现就是,如果真正 DDD 设计,需要花费大量的时间和精力,可能几天都在思考一个问题或者考虑几行代码的编写,但最后也可能没什么结论或结果,并且这个过程是很艰难和痛苦的,所以我后来就变懒了,懒的去思考项目所表现的业务,也不再考虑如何去设计领域模型,只是在考虑如何让框架用起来更爽,DDD.Sample 前两个应用的实际项目,我都是在完善这个框架,比如 Repository 和 UnitOfWork 的设计等等,所以,关于领域模型的设计,就是一堆贫血模型。不过,后来应用的第三个项目,也就是上一个实际项目,我觉得不能再这样下去了,因为没啥意义,框架一遍一遍的套用,而 DDD 却和它没半毛钱关系,所以,我就花了点时间去思考(只是简单的思考):我做这个项目的核心业务是什么?我该如何提炼出核心业务?提炼出核心业务之后,其他的任何实现都是为核心业务服务的,所以,你可以把这个核心业务看成领域模型。

关于第三个应用项目,实际上就是我们园子的“提到我”系统,现在已经应用在新闻评论了,大家可以去瞧瞧,类似为微博的“提到我”,相对比较简单的一个系统,你可以在评论中 @一个人,然后另一个人会接受通知,那这个系统的核心业务是什么?其实就是上面那句话,只不过你需要抽离出一些内容,如果领域专家和开发人员进行交流这个系统的设计,那领域专家的表述就是:你可以在评论中 @一个人,然后另一个人会接受通知,领域专家可能不懂代码设计,他的这个表述就是最直接和最精准的业务,所以,我们需要针对这段话,再和领域专家深入探讨下所蕴含的业务:

  • 你可以在评论中 @一个人 -> @一个人 -> 怎么能得到并确认这个“一个人” -> @匹配规则
  • 另一个人会接受通知 -> 通知 -> 通知所 @的人

所以,@匹配规则通知所 @的人是“提到我”系统的核心业务,确定好核心业务了,那就该具体的实现了,关于这个我没有深入的去考虑,就直接放在了 Mention(提到)中,大致代码:

namespace CNBlogs.Mention.Domain
{
    public class Mention : IAggregateRoot
    {
        private static readonly string SplitRegex = "::  @,";
        private static readonly Regex MentionsRegex = new Regex($"@([^{SplitRegex}]+)", RegexOptions.Compiled);

        public int Id { get; set; }

        public string Content { get; set; }

        public int ContentId { get; set; }

        public AppType AppType { get; set; }

        ...

        //抽离
        public async Task<List<int>> Extract()
        {
            ...
        }

        //通知
        public async Task Notify()
        {
            ...
        }
    }
}

看起来很简单,就是把两个方法放在了 Mention 中,但这简单的操作却好像给 Mention 领域模型生命一样,不再那么贫血,对于复杂系统的业务变化,往往是核心业务的变化,其他的都是为核心业务服务的业务流程,并不能真正称为业务,比如 Application 层的代码,现在领域专家说 @一个人的规则需要改变,或者通知规则需要变化,我们只需要修改 Mention 领域模型的代码就行了,其他的代码并不需要修改,这就是 DDD 设计最浅显的体现。

大致贴下 Application 层的伪代码:

namespace CNBlogs.Mention.Application.Services
{
    public class MentionService : IMentionService
    {
        private IMentionRepository _mentionRepository;
        private IUnitOfWork _unitOfWork;

        public MentionService(IUnitOfWork unitOfWork,
            IMentionRepository mentionRepository)
        {
            _unitOfWork = unitOfWork;
            _mentionRepository = mentionRepository;
        }

        public async Task<SubmitResult> Submit(string content ,int contentId, AppType appType)
        {
            var notifyMentions = new List<Domain.Mention>();
            var existingQuery = _mentionRepository.Get(contentId, appType);
            var mention = new Domain.Mention()
            {
                Content = content,
                ContentId = contentId,
                AppType = appType
            };
            var userIds = await mention.Extract();
            foreach (var userId in userIds)
            {
                var userQuery = existingQuery.Where(x => x.UserId == userId);
                if (await userQuery.AnyAsync())
                {
                    await userQuery.UpdateAsync(x => new Domain.Mention { Content = content, DateUpdated = DateTime.Now });
                }
                else
                {
                    mention.UserId = userId;
                    _unitOfWork.RegisterNew(mention);
                    notifyMentions.Add(mention);
                }
            }
            if (await _unitOfWork.CommitAsync())
            {
                foreach (var notifyMention in notifyMentions)
                {
                    await notifyMention.Notify();
                }
                return new SubmitResult();
            }
            return new SubmitResult { IsSucceed = false };
        }
    }
}

可以看到,Submit 中的操作基本上都是工作流程,先抽取用户,再进行判断更新,然后进行持久化,最后进行通知,没有任何业务体现,所以,如果核心业务发生了变化,这部分的代码并不需要随之改变。

如何 DDD?

151808224336247.png

引自:《Implementing DDD Reading - Strategic Design

如何 DDD?其实答案都在上面的图中,图中的设计在《实现领域驱动设计》书中,被定义为战略建模(Strategic Modeling),主要包含领域、核心域、子域、通用子域、支撑子域、限界上下文、协作上下文、上下文映射图等等概念,我之前的几篇《IDDD 实现领域驱动设计》系统文章,也有过相关的介绍,说实话,我只是当时读过写过有些记忆,现在让我再说任何一个概念,基本上我说不上来,对于我个人来说,战略建模是一种宏观的建模方式,你需要站在高处去俯瞰整个系统,并需要抽离出系统所包含的业务,并将它们一一划分,这个工作是非常难的,推荐几篇战略建模相关的文章:

除了战略建模,还有一种建模方式叫战术建模(Tactical Modeling),主要包含聚合(Aggregate)、实体(Entity)、值对象(Value Objects)、资源库(Repository)、领域服务(Domain Services)、领域事件(Domain Events)、模块(Modules)等等概念。

在《实现领域驱动设计》书中,Scrum 团队(一个实际项目的开发团队)一开始就是采用的战术建模,并且在开发的过程中,他们并不知道战略建模是什么?最后导致了很多问题,书中有个节点就专门讲了“战略设计为什么重要?”,但我个人觉得,战略建模的重要也只是相对而言,它在应对大型复杂性的业务系统设计中,可以充分发挥它的特点,但针对一些相对简单的系统,还不如直接进行战术建模,比如上面说的“提到我”系统。

所以,目前来说,进行战术建模比较现实和有意义,但在进行战术建模之前,我觉得还有一个重要的工作,就是和领域专家进行交流系统业务,这个工作并不包含具体的战术建模该如何设计,比如聚合、实体啥的,和领域专家并不需要讨论这部分内容,而是系统所包含的业务,就像“提到我”系统中,我问我自己“我做这个项目的核心业务是什么?”。

领域专家并不是一个职位,他可以是精通业务的任何人。他们可能了解更多的关于业务领域的背景知识,他们可能是软件产品的设计者,甚至有可能是销售员。

实际项目的实践

好,概念说太多没什么意义,实际应用才有价值,我现在在开发一个 JS 权限申请和审核系统,就是我们园子里的 JS 权限申请,因为现在申请 JS 权限需要发邮件进行申请,对于用户申请和我们处理来说,都比较麻烦并且费时间,所以为了解决这个问题,我们想做把 JS 权限申请做成像申请博客一样,园友填写申请内容,然后我们进行后台审核,效率可以提升很多,大概就是这样的一个系统,真实的不能再真实了,毕竟园友和我们都会实际接触并使用,这也是一个相对较小的系统,我们就拿它来开刀,看看 DDD 的这把刀锋不锋利。

对于 JS 权限申请和审核系统来说,领域专家是谁?应该是园友和管理员,毕竟他们在使用这个系统,没有人比他们更了解其中的业务了,所以他们就是这个系统的领域专家,需要强调的是,虽然有时候领域专家是开发人员,但在一开始探讨业务系统的时候,一定不能牵扯到数据库和代码的设计,我们应该忘掉数据库和代码,只是单纯的站在领域专家的角度,去探讨和思考业务系统,那领域专家该如何表述这个系统的业务呢?

下面我大致的表述下:

用户填写 JS 权限申请内容,管理员后台进行审核。

有没有搞错?就这么简单???好像又无言以对,因为关于 JS 权限申请和审核系统,最简单的表述就是这样,但如何提炼出所蕴含的业务呢?接下来需要我们深入的探讨下,作为领域专家身份的我,绘制了一张大致的业务流程图:

435188-20160413151945473-1912413516.png

上面这张图可以进行反复的修改,每个领域专家都可以发表自己的意见和建议,经过最激烈的探讨才会让业务系统更加准确,当业务系统确定好之后,我们就可以从中抽离出核心业务了,上面这张图,哪些是核心业务?哪些又是业务流程呢?我大致圈一下:

435188-20160413161637941-1309117000.png

方框圈的是核心业务,圆形圈的是实体的状态变化,核心业务一般包含在最简单的描述中,比如“提到我”系统中的表述“抽离”和“通知”,还有一种区分方式:判断其是否经常发生变化,对于业务流程来说,一般是不会发生变化的,变化的是核心业务,DDD 的设计应对的就是这个变化,再大致总结下:

  • 核心业务:验证用户信息,可以称为申请状态改为“待审核”的前提条件,主要是判断用户是否符合要求,前面的“验证申请状态”也属于这一类。
  • 实体状态变化:JS 权限申请就是一个实体,它有自己的生命周期,并且对于用户来说,它是唯一存在的,从上面的图中,我们可以看到 JS 权限申请的状态变化,这是领域所关心的,能改变实体的状态,就是业务。

那领域模型关心的是哪些业务?其实就是能影响 JS 权限申请状态变化的条件,暂时不看用户申请的部分,先看下管理员审核的部分,因为是人工审核的,所以这就有人为因素的产生,这部分我们在领域模型设计的时候,就没有办法把控,所以可以把这部分排除在领域模型之外,后面 JS 权限申请状态的改变,也是由人为进行导致的,也就是说,对于领域模型来说,我们没有办法进行控制 JS 权限申请状态的改变,所以后面的状态改变我们可以看作是业务流程或者工作流程,有人可能会问:“开通 JS 权限”和“消息通知用户”,算不算是业务?其实这部分可以算是业务,因为它是状态改变后的一种行为,我们可以使用领域事件实现它。

跟踪变化最实用的方法是领域事件和事件存储。我们为领域专家所关心的所以状态改变都创建单独的事件类型,事件的名字和属性表明发生了什么样的事件。当命令操作执行完后,系统发出这些领域事件。事件的订阅方可以接收发生在模型上的所有事件。在接收到事件后,订阅方将事件保存在事件存储中。

有点越说越乱的感觉,先暂时概括下我们设计领域模型所包含的东西:

  • 聚合根和实体:JS 权限申请,命名为 JsPermissionApply,具有唯一性。
  • 值对象:申请状态,命名为 Status,包含待审核、审核通过、审核不通过等。
  • 领域事件:处理 JsPermissionApply 状态改变后的一些工作(开通 JS 权限和发送消息通知)。
  • 领域服务:UserAuthenticationService,验证用户是否合法,以及验证此用户是否能创建 JsPermissionApply。
  • 实体验证:基本验证由 JsPermissionApply 自身负责,在 JsPermissionApply 的构造函数中处理。
  • 实体行为:管理员的审核处理 Process,领域事件在这里触发。

UserAuthenticationService 所做的工作就是上面图中第一个圈和第一个方框的内容,总的概述就是验证用户是否能创建 JsPermissionApply?我之前考虑用工厂实现,但感觉还是不太妥,因为工厂是为创建复杂实体服务的,内部会有一些复杂的操作,对于一些简单的实体创建,我们直接用实体的构造函数进行创建就行,比如 JsPermissionApply 的创建,既然用工厂实现不合适,那直接将操作放在 JsPermissionApply 中会怎样呢?验证自己能否被创建?想想还是有些别扭,所以还是用 UserAuthenticationService 领域服务实现吧,况且领域服务的定义就是如此。

领域服务表示一个无状态的操作,它用于实现特定于某个领域的任务,当某个操作不适合放在聚合和值对象上时,最好的方式便是使用领域服务。

另外,关于实体、值对象、领域事件、领域服务和仓储接口的实现,最好在不同的项目中,如果再同一个项目中的话,可能会造成循环引用的情况,比如仓储接口引用了实体,领域服务引用了仓储接口,如果实体和领域服务实现在同一个项目,就会出现循环引用的问题。

再来总结下,我们分析系统和设计领域模型的步骤:先和领域专家探讨业务系统,经过反反复复的研究,抽离出业务系统的核心业务,然后用战术建模的方式设计领域模型,最后用代码进行实现。领域模型设计好了之后,下面就开始用代码实现了,在代码实现的时候,最好解决方案中只有领域层、基础设施层和单元测试,并且一开始设计的时候,先编写领域层的代码,然后再编写单元测试,最后进行不断的测试和完善,关于数据的持久化,现在最好不要关注,尽量用 Mock 的方式模拟数据。

我先贴一下 JsPermissionApply 实体的部分代码:

using CNBlogs.Apply.Domain.DomainEvents;
using CNBlogs.Apply.Domain.ValueObjects;
using System;
using Microsoft.Practices.Unity;
using CNBlogs.Apply.Infrastructure.IoC.Contracts;

namespace CNBlogs.Apply.Domain
{
    public class JsPermissionApply : IAggregateRoot
    {
        private IEventBus eventBus;

        public JsPermissionApply()
        { }

        public JsPermissionApply(string reason, int userId, string ip)
        {
            if (string.IsNullOrEmpty(reason))
            {
                throw new ArgumentException("申请内容不能为空");
            }
            if (reason.Length > 3000)
            {
                throw new ArgumentException("申请内容超出最大长度");
            }
            if (userId == 0)
            {
                throw new ArgumentException("用户Id为0");
            }
            this.Reason = reason;
            this.UserId = userId;
            this.Ip = ip;
            this.Status = Status.Wait;
        }

        public int Id { get; private set; }

        public string Reason { get; private set; }

        public int UserId { get; private set; }

        public Status Status { get; private set; } = Status.Wait;

        public string Ip { get; private set; }

        public DateTime ApplyTime { get; private set; } = DateTime.Now;

        public string ReplyContent { get; private set; }

        public DateTime? ApprovedTime { get; private set; }

        public bool IsActive { get; private set; } = true;

        public void Process(string replyContent, Status status)
        {
            this.ReplyContent = replyContent;
            this.Status = status;
            this.ApprovedTime = DateTime.Now;

            eventBus = IocContainer.Default.Resolve<IEventBus>();
            if (this.Status == Status.Pass)
            {
                eventBus.Publish(new JsPermissionOpenedEvent() { UserId = this.UserId });
                eventBus.Publish(new MessageSentEvent() { Title = "系统通知", Content = "审核通过", RecipientId = this.UserId });
            }
            else if (this.Status == Status.Deny)
            {
                eventBus.Publish(new MessageSentEvent() { Title = "系统通知", Content = "审核不通过", RecipientId = this.UserId });
            }
        }
    }
}

JsPermissionApplyTest 单元测试的代码:

using CNBlogs.Apply.Domain.DomainServices;
using CNBlogs.Apply.Domain.ValueObjects;
using CNBlogs.Apply.Infrastructure.Interfaces;
using CNBlogs.Apply.Infrastructure.IoC.Contracts;
using CNBlogs.Apply.Repository.Interfaces;
using System;
using System.Data.Entity;
using System.Threading.Tasks;
using Xunit;
using Microsoft.Practices.Unity;

namespace CNBlogs.Apply.Domain.Tests
{
    public class JsPermissionApplyTest
    {
        private IUserAuthenticationService _userAuthenticationService;
        private IJsPermissionApplyRepository _jsPermissionApplyRepository;
        private IUnitOfWork _unitOfWork;

        public JsPermissionApplyTest()
        {
            CNBlogs.Apply.BootStrapper.Startup.Configure();

            _userAuthenticationService = IocContainer.Default.Resolve<IUserAuthenticationService>();
            _jsPermissionApplyRepository = IocContainer.Default.Resolve<IJsPermissionApplyRepository>();
            _unitOfWork = IocContainer.Default.Resolve<IUnitOfWork>();
        }

        [Fact]
        public async Task Apply()
        {
            var userId = 1;
            var verfiyResult = await _userAuthenticationService.Verfiy(userId);
            Console.WriteLine(verfiyResult);
            Assert.Empty(verfiyResult);

            var jsPermissionApply = new JsPermissionApply("我要申请JS权限", userId, "");
            _unitOfWork.RegisterNew(jsPermissionApply);
            Assert.True(await _unitOfWork.CommitAsync());
        }

        [Fact]
        public async Task ProcessApply()
        {
            var userId = 1;
            var jsPermissionApply = await _jsPermissionApplyRepository.GetByUserId(userId).FirstOrDefaultAsync();
            Assert.NotNull(jsPermissionApply);

            jsPermissionApply.Process("审核通过", Status.Pass);
            _unitOfWork.RegisterDirty(jsPermissionApply);
            Assert.True(await _unitOfWork.CommitAsync());
        }
    }
}

代码我就不分析了,基本上是按照我们上面的设计方案实现的,本来想在仓储层模拟数据的,但时间有限,还是使用的 EF 进行数据的持久化和访问,完整的解决方案目录:

435188-20160414092118520-1940032472.png

开源地址:https://github.com/yuezhongxin/CNBlogs.Apply.Sample

上面提交的代码,只是一开始的实现,有些地方可能没有考虑全面,代码也可能会有些粗糙,但因为不是简简单单的示例 Demo,而是实际项目,所以后面我会不断的进行完善,大家如果有什么意见或建议,欢迎探讨~~~


实现领域驱动设计的方式有很多种,你可以战略设计、你也可以战术设计、你可以直接面向对象编写代码、你也可以和领域专家只画一张白板图、又或者写一篇分析业务系统的文章,但就像埃文斯(Eric Evans)的书名一样《领域驱动设计:软件核心复杂性应对之道》,领域驱动设计的核心目的,就是应对软件业务系统的复杂性,所以,不管哪种实现方式,只要能达到这个目的,那就是好的实现领域驱动设计的方式。

JS 权限申请和审核系统还没完,下面又要加一个 Blog 地址更改申请和审核系统,它们会碰撞什么样的火花呢?拭目以待吧。





本文转自田园里的蟋蟀博客园博客,原文链接:http://www.cnblogs.com/xishuai/p/how-to-implement-ddd.html,如需转载请自行联系原作者

网友评论

登录后评论
0/500
评论