连续写了两篇文章,这一篇我想是序的完结篇了。结合用户注册的例子再将他简单丰富一下。在这里只添加一个简单需求,就是用户注册成功后给用户发一封邮件。补充一下之前的代码
public class DomainService { public void Register(User user) { if (_userRepository.IsLoginIdExist(user.LoginId)) { throw new Exception("用户名已存在"); } _userRepository.Add(user); MailService.Send(user.Email, "邮件内容"); } }
上面的代码是存在一点问题的,了解DDD的人都知道,此时user并没有持久化或者持久化是否成功是不确定的,假设此时持久化user失败了,但邮件却发送出去了,这显然不是我们想要的结果。怎么办?我能想到的是两种办法。
第一种:创建一个发送邮件的model。
public class MailMessage { public MailMessage(string receiver, string content) { this.Receiver = receiver; this.Content = content; } public string Receiver { get; private set; } public string Content { get; private set; } } public class DomainService { public void Register(User user) { if (_userRepository.IsLoginIdExist(user.LoginId)) { throw new Exception("用户名已存在"); } _userRepository.Add(user); _mailRepository.Add(new MailMessage(user.Email, "邮件内容")); } }
在添加用户的时候同时添加一条邮件消息,这样他们将会在同一个事务中,要么一起成功,要么一起失败。最后再设计个计划任务,从邮件记录表中取出记录依次发送邮件,发送成功的可以标记一下,至于怎么做就不细讲了。
第二种:就是这一篇我要介绍的使用事件。
public class UserRegistered : IEvent { public UserRegistered(string name, string email) { this.Name = name; this.Email = email; } public string Name { get; private set; } public string Email { get; private set; } } public class UserRegisteredHandler : IEventHandler<UserRegistered> { public void Handle(UserRegistered @event) { //TODO.. 发送邮件 } } public class User : IEventPublisher { private readonly IList<IEvent> _uncommittedEvents = new List<IEvent>(); IEnumerable<IEvent> IEventPublisher.Events { get { return this._uncommittedEvents; } } public User(string name, string password, string email) { this.Name = name; this.Password = password; this.Email = email; _uncommittedEvents.Add(new UserRegistered(name, email)); } public string Name { get; private set; } public string Password { get; private set; } public string Email { get; private set; } }
这样用户注册会产生一个事件。持久化成功后,会将事件发布出去,这样EventBus就会监听并处理此事件。上面的代码可能阅读理解起来不是那么的直白,具体的实现起来也并非就这么简单,只是提出一种方法。具体实现我的开源代码里也有相关例子http://thinknet.codeplex.com
总结
以上三篇文章我也主要是从写代码的角度去介绍如何DDD,强调一下我不是在教你如何写代码,只是为了展示用DDD如何实现,领域里的模型更应该能表达业务,他的价值更并不仅于此。而且以上的描述不一定完全正确,也不是告诉你一定要如何做,这也需要你自己的思考,如果有不对的地方欢迎你的指正,毕竟DDD我在学习过程中,也能从中受益。
如果我们过多的精力花在如何写代码上,可能是收集的工具类库还不强大,或者是还没有一个能够方便快捷开发的框架,当然一个好的框架带来的好处会很多。一个框架终究是有办法和技术能力去实现完成的,但是如何分析和理解业务,然后从中挖掘出便于阅读和表达业务的模型确定一件不容易的事情,他并不是通过某种技术办法就能实现的。所以我个人觉得设计模型,划分界限上下文是需要不断的积累领域业务知识才能做到的。
“领域驱动设计”和“实现领域驱动”这两本书应该是最经典的了,知识点也很多,阅读此书你会得到更多的收获!
随笔分类 - ThinkNet