拨乱反正:DDD 回归具体的业务场景,Domain Model 再再重新设计
2014-07-14 10:31
405 查看
首先,把最真挚的情感送与梅西,加油!
View Code
除了短消息发送服务,我们还可以实现邮箱发送服务(业务上的 SendMailMessageService),其内部可以调用基础层的发送邮件服务(技术上的 SendMailService),这两个概念容易搞混,需要区分开。通过这个消息领域服务,我们可以在其他的应用程序中进行调用,使用什么消息发送,只需要在调用的时候注入相应的接口实现即可,为什么这么厉害?因为它是所有消息发送的抽象描述,哈哈。
我们再来看下单元测试代码:
从单元测试的代码我们可以很清楚的描述发消息这个业务用例,首先创建一个发送短消息的领域服务对象,然后分别创建发送人和接收人对象,标识分别为:sender 和 recipient,下面创建一个消息对象,然后调用领域服务传入消息对象参数进行发送,完成整个的发消息业务。虽然看起来简单,也很容易造成误解,有人也会怀疑领域模型就是这样?其实就是这样,测试用例代码描述的就是业务用例,它体现出来的就是领域模型,当然,SendMessage 方法中只有一段代码,但是它所表达的就是这个业务场景的具体体现。
有时候领域模型设计不出来,可以先写领域模型测试用例的伪代码,因为领域模型的测试用例反应的就是业务需求,一个完成业务场景的具体过程,这也是一种开发的方式,DDD+TDD=?(某一方面的相加)
其实任何存在具体的业务场景,不管简单或不简单,都可以使用领域驱动设计开发,领域驱动设计应对的是复杂度,这个复杂度可以理解为未来的复杂度,如果在前期开发的时候,领域模型设计的好,那么后面改东西就会很方便,当然到现在为止,我还只是道听途说,并没有真正体会它的好处,但是我很期待,我想那种感觉应该会很美妙。
关于本篇博文内容就是这些,不管错与对,欢迎大家讨论,只有这样,大家才可以学到更多,不只是你我哦。
MessageManager 项目开源地址:
GitHub 开源地址:https://github.com/yuezhongxin/MessageManager
ASP.NET MVC 发布地址:http://www.xishuaiblog.com:8081/
ASP.NET WebAPI 发布地址:http://www.xishuaiblog.com:8082/api/Message/GetMessagesBySendUser/小菜
如果你觉得本篇文章对你有所帮助,请点击右下部“推荐”,^_^
写在前面
/** * author:xishuai * address:https://www.github.com/yuezhongxin/MessageManager **/ using MessageManager.Domain.Entity; namespace MessageManager.Domain.DomainService { /// <summary> /// SendShortMessag领域服务实现-短消息发送 /// </summary> public class SendShortMessageService : ISendMessageService { public bool SendMessage(Message message) { return true; } } }
View Code
除了短消息发送服务,我们还可以实现邮箱发送服务(业务上的 SendMailMessageService),其内部可以调用基础层的发送邮件服务(技术上的 SendMailService),这两个概念容易搞混,需要区分开。通过这个消息领域服务,我们可以在其他的应用程序中进行调用,使用什么消息发送,只需要在调用的时候注入相应的接口实现即可,为什么这么厉害?因为它是所有消息发送的抽象描述,哈哈。
我们再来看下单元测试代码:
/** * author:xishuai * address:https://www.github.com/yuezhongxin/MessageManager **/ using MessageManager.Domain.DomainService; using MessageManager.Domain.Entity; using MessageManager.Domain.ValueObject; using System; using Xunit; namespace MessageManager.Domain.Tests { public class MessageDomainTest { /// <summary> /// 消息发送-短消息 /// </summary> [Fact] public void DomainTest_SendShortMessage() { ISendMessageService sendMessageService = new SendShortMessageService(); IContact sender = new Sender("sender"); IContact recipient = new Recipient("recipient"); Message message = new Message("title", "content ", sender, recipient); Assert.True(sendMessageService.SendMessage(message)); } } }
从单元测试的代码我们可以很清楚的描述发消息这个业务用例,首先创建一个发送短消息的领域服务对象,然后分别创建发送人和接收人对象,标识分别为:sender 和 recipient,下面创建一个消息对象,然后调用领域服务传入消息对象参数进行发送,完成整个的发消息业务。虽然看起来简单,也很容易造成误解,有人也会怀疑领域模型就是这样?其实就是这样,测试用例代码描述的就是业务用例,它体现出来的就是领域模型,当然,SendMessage 方法中只有一段代码,但是它所表达的就是这个业务场景的具体体现。
有时候领域模型设计不出来,可以先写领域模型测试用例的伪代码,因为领域模型的测试用例反应的就是业务需求,一个完成业务场景的具体过程,这也是一种开发的方式,DDD+TDD=?(某一方面的相加)
后记
有朋友可能会觉得:如此简单的业务场景,使用领域驱动设计开发,会不会太简单了?或者说根本不适合?我只想说:大哥,如果你觉得简单,请收了我,可好?其实任何存在具体的业务场景,不管简单或不简单,都可以使用领域驱动设计开发,领域驱动设计应对的是复杂度,这个复杂度可以理解为未来的复杂度,如果在前期开发的时候,领域模型设计的好,那么后面改东西就会很方便,当然到现在为止,我还只是道听途说,并没有真正体会它的好处,但是我很期待,我想那种感觉应该会很美妙。
关于本篇博文内容就是这些,不管错与对,欢迎大家讨论,只有这样,大家才可以学到更多,不只是你我哦。
MessageManager 项目开源地址:
GitHub 开源地址:https://github.com/yuezhongxin/MessageManager
ASP.NET MVC 发布地址:http://www.xishuaiblog.com:8081/
ASP.NET WebAPI 发布地址:http://www.xishuaiblog.com:8082/api/Message/GetMessagesBySendUser/小菜
如果你觉得本篇文章对你有所帮助,请点击右下部“推荐”,^_^
相关文章推荐
- DDD 回归具体的业务场景,Domain Model 再再重新设计
- No zuo no die:DDD 应对具体业务场景,Domain Model 重新设计
- DDD 应对具体业务场景,Domain Model 重新设计
- No zuo no die:DDD 应对具体业务场景,Domain Model 重新设计
- DDD(领域驱动设计)应对具体业务场景,如何聚焦 Domain Model(领域模型)?
- DDD(领域驱动设计)应对具体业务场景,Domain Model(领域模型)到底如何设计?
- 一缕阳光:DDD(领域驱动设计)应对具体业务场景,如何聚焦 Domain Model(领域模型)?
- 拨开迷雾,找回自我:DDD 应对具体业务场景,Domain Model 到底如何设计?
- 拨开迷雾,找回自我:DDD 应对具体业务场景,Domain Model 到底如何设计?
- 设计窘境:来自 Repository 的一丝线索,Domain Model 再重新设计
- DDD 领域驱动设计-如何完善 Domain Model(领域模型)?
- Domain Model:业务对象的进一步设计
- Domain Model:业务对象的进一步设计
- 来自 Repository 的一丝线索,Domain Model 再重新设计
- Domain Model:业务对象的进一步设计2
- Domain Model:业务对象的进一步设计2
- 贫血模型;DTO:数据传输对象(Data Transfer Object);AutoMapper ;Domain Model(领域模型);DDD(领域驱动设计)
- 设计窘境:来自 Repository 的一丝线索,Domain Model 再重新设计
- 业务逻辑层:Model 层的分析