Domain Model（领域模型）

时间：2022-04-14 23:28:33

Domain Model（领域模型）

上一篇：《DDD 领域驱动设计－如何 DDD？》

开源地址：https://github.com/yuezhongxin/CNBlogs.Apply.Sample（代码已更新）

阅读目录：

  • JsPermissionApply 生命周期
  • 改进 JsPermissionApply 实体
  • 重命名 UserAuthenticationService
  • 改进 JsPermissionApplyRepository
  • 改进领域单元测试

如何完善领域模型？指的是完善 JS 权限申请领域模型，也就是 JsPermissionApply Domain Model。

在上篇博文中，关于 JsPermissionApply 领域模型的设计，只是一个刚出生的“婴儿”，还不是很成熟，并且很多细致的业务并没有考虑到，本篇将对 JsPermissionApply 领域模型进行完善，如何完善呢？望着解决方案中的项目和代码，好像又束手无策，这时候如果没有一点思考，而是直接编写代码，到最后你会发现 DDD 又变成了脚本式开发，所以，我们在做领域模型开发的时候，需要一个切入点，把更多的精力放在业务上，而不是实现的代码上，那这个切入点是什么呢？没错，就是上篇博文中的“业务流程图”，又简单完善了下：

Domain Model（领域模型）

1. JsPermissionApply 生命周期

在完善 JsPermissionApply 领域模型之前，我们需要先探讨下 JsPermissionApply 实体的生命周期，这个在接下来完善的时候会非常重要，能影响 JsPermissionApply 实体生命周期的唯一因素，就是改变其自身的状态，从上面的业务流程图中，我们就可以看到改变状态的地方：“申请状态为待审核”、“申请状态改为通过”、“申请状态改为未通过”、“申请状态改为锁定”，能改变实体状态的行为都是业务行为，这个在领域模型设计的时候，要重点关注。

用户申请 JS 权限的最终目的是开通 JS 权限，对于 JsPermissionApply 实体而言，就是自身状态为“通过”，所以，我们可以认为，当 JsPermissionApply 实体状态为“通过”的时候，那么 JsPermissionApply 实体的生命周期就结束了，JsPermissionApply 生命周期开始的时候，就是创建 JsPermissionApply 实体对象的时候，也就是实体状态为“待审核”的时候。

好，上面的分析听起来很有道理，感觉应该没什么问题，但在实现 JsPermissionApplyRepository 的时候，就会发现有很多问题（后面会说到），JsPermissionApply 的关键字是 Apply（申请），对于一个申请来说，生命周期的结束就是其经过了审核，不论是通过还是不通过，锁定还是不锁定，这个申请的生命周期就结束了，再次申请就是另一个 JsPermissionApply 实体对象了，对于实体生命周期有效期内，其实体必须是唯一性的。

导致上面两种分析的不同，主要是关注点不同，第一种以用户为中心，第二种以申请为中心，以用户为中心的分析方式，在我们平常的开发过程中会经常遇到，因为我们开发的系统基本上都是给人用的，所以很多业务都是围绕用户进行展开，好像没有什么不对，但如果这样进行分析设计，那么每个系统的核心域都是用户了，领域模型也变成了用户领域模型，所以，我们在分析业务系统的时候，最好进行细分，并把用户的因素隔离开，最后把核心和非核心进行区分开。

2. 改进 JsPermissionApply 实体

先看下之前 JsPermissionApply 实体的部分代码：

namespace CNBlogs.Apply.Domain { public class JsPermissionApply : IAggregateRoot { private IEventBus eventBus; ... 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 }); } } } }

Process 的设计会让领域专家看不懂，为什么？看下对应的单元测试：

[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()); }

Process 是啥？如果领域专家不是开发人员，通过一个申请，他会认为应该有一个直接通过申请的操作，而不是调用一个不知道干啥的 Process 方法，然后再传几个不知道的参数，在 IDDD 书中，代码也是和领域专家交流的通用语言之一，所以，开发人员编写的代码需要让领域专家看懂，至少代码要表达一个最直接的业务操作。

所以，对于申请的处理，通过就是通过，不通过就是不通过，要用代码表达的简单粗暴。

改进代码：

namespace CNBlogs.Apply.Domain { public class JsPermissionApply : IAggregateRoot { private IEventBus eventBus; ... public async Task Pass() { this.Status = Status.Pass; this.ApprovedTime = DateTime.Now; this.ReplyContent = "恭喜您！您的JS权限申请已通过审批。"; eventBus = IocContainer.Default.Resolve<IEventBus>(); await eventBus.Publish(new JsPermissionOpenedEvent() { UserId = this.UserId }); await eventBus.Publish(new MessageSentEvent() { Title = "您的JS权限申请已批准", Content = this.ReplyContent, RecipientId = this.UserId }); } public async Task Deny(string replyContent) { this.Status = Status.Deny; this.ApprovedTime = DateTime.Now; this.ReplyContent = $"抱歉！您的JS权限申请没有被批准，{(string.IsNullOrEmpty(replyContent) ? "" : $"具体原因：{replyContent}<br/>")}麻烦您重新填写申请理由。"; eventBus = IocContainer.Default.Resolve<IEventBus>(); await eventBus.Publish(new MessageSentEvent() { Title = "您的JS权限申请未通过审批", Content = this.ReplyContent, RecipientId = this.UserId }); } public async Task Lock() { this.Status = Status.Lock; this.ApprovedTime = DateTime.Now; this.ReplyContent = "抱歉！您的JS权限申请没有被批准，并且申请已被锁定，具体请联系contact@cnblogs.com。"; eventBus = IocContainer.Default.Resolve<IEventBus>(); await eventBus.Publish(new MessageSentEvent() { Title = "您的JS权限申请已被锁定", Content = this.ReplyContent, RecipientId = this.UserId }); } } }

这样改进还有一个好处，就是改变 JsPermissionApply 状态会变的更加明了，也更加受保护，什么意思？比如之前的 Process 的方法，我们可以通过参数任意改变 JsPermissionApply 的状态，这是不被允许的，现在我们只能通过三个操作改变对应的三种状态。

JsPermissionApply 实体改变了，对应的单元测试也要进行更新（后面讲到）。

3. 重命名 UserAuthenticationService

UserAuthenticationService 是领域服务，一看到这个命名，会认为这是关于用户验证的服务，我们再看上面的流程图，会发现有一个“验证用户信息”操作，但前面还有一个“验证申请状态”操作，而在之前的设计实现中，这两个操作都是放在 UserAuthenticationService 中的，如下：

namespace CNBlogs.Apply.Domain.DomainServices { public class UserAuthenticationService : IUserAuthenticationService { private IJsPermissionApplyRepository _jsPermissionApplyRepository; public UserAuthenticationService(IJsPermissionApplyRepository jsPermissionApplyRepository) { _jsPermissionApplyRepository = jsPermissionApplyRepository; } public async Task<string> Verfiy(int userId) { if (!await UserService.IsHasBlog(userId)) { return "必须先开通博客，才能申请JS权限"; } var entity = await _jsPermissionApplyRepository.GetByUserId(userId).FirstOrDefaultAsync(); if (entity != null) { if (entity.Status == Status.Pass) { return "您的JS权限申请正在处理中，请稍后"; } if (entity.Status == Status.Lock) { return "您暂时无法申请JS权限，请联系contact@cnblogs.com"; } } return string.Empty; } } }

IsHasBlog 属于用户验证，但下面的 jsPermissionApply.Status 验证就不属于了，放在 UserAuthenticationService 中也不合适，我的想法是把这部分验证独立出来，用 ApplyAuthenticationService 领域服务实现，后来仔细一想，似乎和上面实体生命周期遇到的问题有些类似，误把用户当作核心考虑了，在 JS 权限申请和审核系统中，对于用户的验证，其实就是对申请的验证，所验证的最终目的是：某个用户是否符合要求进行申请操作？

所以，对于申请相关的验证操作，应该命名为 ApplyAuthenticationService，并且验证代码都放在其中。

改进代码：

namespace CNBlogs.Apply.Domain.DomainServices { public class ApplyAuthenticationService : IApplyAuthenticationService { private IJsPermissionApplyRepository _jsPermissionApplyRepository; public ApplyAuthenticationService(IJsPermissionApplyRepository jsPermissionApplyRepository) { _jsPermissionApplyRepository = jsPermissionApplyRepository; } public async Task<string> Verfiy(int userId) { if (!await UserService.IsHasBlog(userId)) { return "必须先开通博客，才能申请JS权限"; } var entity = await _jsPermissionApplyRepository.GetEffective(userId).FirstOrDefaultAsync(); if (entity != null) { if (entity.Status == Status.Pass) { return "您的JS权限申请已开通，请勿重复申请"; } if (entity.Status == Status.Wait) { return "您的JS权限申请正在处理中，请稍后"; } if (entity.Status == Status.Lock) { return "您暂时无法申请JS权限，请联系contact@cnblogs.com"; } } return string.Empty; } } }

除了 UserAuthenticationService 重命名为 ApplyAuthenticationService，还增加了对 JsPermissionApply 状态为 Lock 的验证，并且 IJsPermissionApplyRepository 的 GetByUserId 调用改为了 GetEffective，这个下面会讲到。

4. 改进 JsPermissionApplyRepository

原先的 IJsPermissionApplyRepository 设计：

namespace CNBlogs.Apply.Repository.Interfaces { public interface IJsPermissionApplyRepository : IRepository<JsPermissionApply> { IQueryable<JsPermissionApply> GetByUserId(int userId); } }

这样的 IJsPermissionApplyRepository 的设计，看似没什么问题，并且问题也不出现在实现，而是出现在调用的时候，GetByUserId 会在两个地方调用：

  • ApplyAuthenticationService.Verfiy 调用：获取 JsPermissionApply 实体对象，用于状态的验证，判断是否符合申请的要求。
  • 领域的单元测试代码中（或者应用层）：获取 JsPermissionApply 实体对象，用于更新其状态。

对于上面两个调用方来说，GetByUserId 太模糊了，甚至不知道调用的是什么东西？并且这两个地方的调用，获取的 JsPermissionApply 实体对象也并不相同，严格来说，应该是不同状态下的 JsPermissionApply 实体对象，我们仔细分析下：

  • ApplyAuthenticationService.Verfiy 调用：判断是否符合申请的要求。什么情况下会符合申请要求呢？就是当状态为“未通过”的时候，对于申请验证来说，可以称之为“有效的”申请，相反，获取用于申请验证的 JsPermissionApply 实体对象，应该称为“无效的”，调用命名为 GetInvalid。
  • 领域的单元测试代码中（或者应用层）：用于更新 JsPermissionApply 实体状态。什么状态下的 JsPermissionApply 实体，可以更新其状态呢？答案就是状态为“待审核”，所以这个调用应该获取状态为“待审核”的 JsPermissionApply 实体对象，调用命名为 GetWaiting。

改进代码：

namespace CNBlogs.Apply.Repository { public class JsPermissionApplyRepository : BaseRepository<JsPermissionApply>, IJsPermissionApplyRepository { public JsPermissionApplyRepository(IDbContext dbContext) : base(dbContext) { } public IQueryable<JsPermissionApply> GetInvalid(int userId) { return _entities.Where(x => x.UserId == userId && x.Status != Status.Deny && x.IsActive); } public IQueryable<JsPermissionApply> GetWaiting(int userId) { return _entities.Where(x => x.UserId == userId && x.Status == Status.Wait && x.IsActive); } } }

5. 改进领域单元测试

原先的单元测试代码：

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()); } } }

看起来似乎没什么问题，一个申请和一个审核测试，但我们仔细看上面的业务流程图，会发现这个测试代码并不能完全覆盖所有的业务，并且这个测试代码也有些太敷衍了，在测试驱动开发中，测试代码就是所有的业务表达，它应该是项目中最全面和最精细的代码，在领域驱动设计中，当领域层的代码完成后，领域专家查看的时候，不会看领域层，而是直接看单元测试中的代码，因为领域专家不懂代码，并且他也不懂你是如何实现的，它关心的是我该如何使用它？我想要的业务操作，你有没有完全实现？单元测试就是最好的体现。

我们该如何改进呢？还是回归到上面的业务流程图，并从中归纳出领域专家想要的几个操作：

  • 填写 JS 权限申请（需要填写申请理由）
  • 通过 JS 权限申请
  • 拒绝 JS 权限申请（需要填写拒绝原因）
  • 锁定 JS 权限申请
  • 删除（待考虑）

上面这几个操作，都必须在单元测试代码中有所体现，并且尽量让测试颗粒化，比如一个验证操作，你可以对不同的参数编写不同的单元测试代码。

改进代码：

namespace CNBlogs.Apply.Domain.Tests { public class JsPermissionApplyTest { private IApplyAuthenticationService _applyAuthenticationService; private IJsPermissionApplyRepository _jsPermissionApplyRepository; private IUnitOfWork _unitOfWork; public JsPermissionApplyTest() { CNBlogs.Apply.BootStrapper.Startup.Configure(); _applyAuthenticationService = IocContainer.Default.Resolve<IApplyAuthenticationService>(); _jsPermissionApplyRepository = IocContainer.Default.Resolve<IJsPermissionApplyRepository>(); _unitOfWork = IocContainer.Default.Resolve<IUnitOfWork>(); } [Fact] public async Task ApplyTest() { var userId = 1; var verfiyResult = await _applyAuthenticationService.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_WithPassTest() { var userId = 1; var jsPermissionApply = await _jsPermissionApplyRepository.GetWaiting(userId).FirstOrDefaultAsync(); Assert.NotNull(jsPermissionApply); await jsPermissionApply.Pass(); _unitOfWork.RegisterDirty(jsPermissionApply); Assert.True(await _unitOfWork.CommitAsync()); } [Fact] public async Task ProcessApply_WithDenyTest() { var userId = 1; var jsPermissionApply = await _jsPermissionApplyRepository.GetWaiting(userId).FirstOrDefaultAsync(); Assert.NotNull(jsPermissionApply); await jsPermissionApply.Deny("理由太简单了。"); _unitOfWork.RegisterDirty(jsPermissionApply); Assert.True(await _unitOfWork.CommitAsync()); } [Fact] public async Task ProcessApply_WithLockTest() { var userId = 1; var jsPermissionApply = await _jsPermissionApplyRepository.GetWaiting(userId).FirstOrDefaultAsync(); Assert.NotNull(jsPermissionApply); await jsPermissionApply.Lock(); _unitOfWork.RegisterDirty(jsPermissionApply); Assert.True(await _unitOfWork.CommitAsync()); } } }

改进好了代码之后，对于开发人员来说，任务似乎完成了，但对于领域专家来说，仅仅是个开始，因为他必须要通过提供的四个操作，来验证各种情况下的业务操作是否正确，我们来归纳下：

  • 申请 -> 申请：ApplyTest -> ApplyTest
  • 申请 -> 通过：ApplyTest -> ProcessApply_WithPassTest
  • 申请 -> 拒绝：ApplyTest -> ProcessApply_WithDenyTest
  • 申请 -> 锁定：ApplyTest -> ProcessApply_WithLockTest
  • 申请 -> 通过 -> 申请：ApplyTest -> ProcessApply_WithPassTest -> ApplyTest
  • 申请 -> 拒绝 -> 申请：ApplyTest -> ProcessApply_WithDenyTest -> ApplyTest
  • 申请 -> 锁定 -> 申请：ApplyTest -> ProcessApply_WithLockTest -> ApplyTest

确认上面的所有测试都通过之后，就说明 JsPermissionApply 领域模型设计的还算可以。

DDD 倾向于“测试先行，逐步改进”的设计思路。测试代码本身便是通用语言在程序中的表达，在开发人员的帮助下，领域专家可以阅读测试代码来检验领域对象是否满足业务需求。

当领域层的代码基本完成之后，就可以在地基上添砖加瓦了，后面的实现都是工作流程的实现，没有任何业务的包含，比如上面对领域层的单元测试，其实就是应用层的实现，在添砖加瓦的过程中，切记地基的重要性，否则即使盖再高的摩天大楼，地基不稳，也照样垮塌。

实际项目的 DDD 应用很有挑战，也会很有意思。????

无意间发现了 Visual Studio 2015 Update 2 一个很实用的功能：

Domain Model（领域模型）

标签：

相关文章