标签：
注：科比今天要退役了，我是 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 中的操作基本上都是工作流程，先抽取用户，再进行判断更新，然后进行持久化，最后进行通知，没有任何业务体现，所以，如果核心业务发生了变化，这部分的代码并不需要随之改变。
引自：《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 权限申请和审核系统，最简单的表述就是这样，但如何提炼出所蕴含的业务呢？接下来需要我们深入的探讨下，作为领域专家身份的我，绘制了一张大致的业务流程图：
上面这张图可以进行反复的修改，每个领域专家都可以发表自己的意见和建议，经过最激烈的探讨才会让业务系统更加准确，当业务系统确定好之后，我们就可以从中抽离出核心业务了，上面这张图，哪些是核心业务？哪些又是业务流程呢？我大致圈一下：
方框圈的是核心业务，圆形圈的是实体的状态变化，核心业务一般包含在最简单的描述中，比如“提到我”系统中的表述“抽离”和“通知”，还有一种区分方式：判断其是否经常发生变化，对于业务流程来说，一般是不会发生变化的，变化的是核心业务，DDD 的设计应对的就是这个变化，再大致总结下：
那领域模型关心的是哪些业务？其实就是能影响 JS 权限申请状态变化的条件，暂时不看用户申请的部分，先看下管理员审核的部分，因为是人工审核的，所以这就有人为因素的产生，这部分我们在领域模型设计的时候，就没有办法把控，所以可以把这部分排除在领域模型之外，后面 JS 权限申请状态的改变，也是由人为进行导致的，也就是说，对于领域模型来说，我们没有办法进行控制 JS 权限申请状态的改变，所以后面的状态改变我们可以看作是业务流程或者工作流程，有人可能会问：“开通 JS 权限”和“消息通知用户”，算不算是业务？其实这部分可以算是业务，因为它是状态改变后的一种行为，我们可以使用领域事件实现它。
跟踪变化最实用的方法是领域事件和事件存储。我们为领域专家所关心的所以状态改变都创建单独的事件类型，事件的名字和属性表明发生了什么样的事件。当命令操作执行完后，系统发出这些领域事件。事件的订阅方可以接收发生在模型上的所有事件。在接收到事件后，订阅方将事件保存在事件存储中。
有点越说越乱的感觉，先暂时概括下我们设计领域模型所包含的东西：
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 =