前言
今天开始,更新领域驱动设计系统架构落地,由于白天要上班, 更新会有点慢。
01 基础概念
什么是DDD
从pop(面向过程),oop(面向对象),到最后的ddd(领域),改变的都是我们的编程思维,好的架构,不仅减轻了我们程序员的工作量,也提升了代码的可读性,减轻了维护的工作量,
02 DP(Domain Primitive)
初看DP,很难理解它是什么,
我个人认为它是一个基础的值对象,就像Integer、String类型一样,(个人理解,大神勿喷)
DP是模型,方法,架构的技术,在代码中无处不在
案例一(用户登录)
public User Login(string userName,string passWord)
{
if (userName == null|| userName =="") {
throw new Exception("账号不能为空");
}
if (passWord == null || passWord == "")
{
throw new Exception("密码不能为空");
}
if (userName.Length < 6)
{
throw new Exception("账号过短");
}
passWord = DESHelper.Encrypt(passWord);//密码加密
/*
* 等等校验逻辑
*/
return userRepository.GetUser(userName, passWord);
}
这样是不是我们日常写的代码,登录一个方法里面,实际业务逻辑和校验逻辑混合在一起,很难看出实际业务逻辑是什么
数据验证代码不能复用,在登录的时候需要写一遍,在添加的时候是不是也要写一遍,在修改的时候是不是也要写一遍,如果说可以把这些代码封装一下,你觉得怎么封装好
DP的引出
这个时候,如果对象的字段可能会有自己的校验或者业务逻辑,我们初始反应可能就是写个帮助类,或者静态类,但是今天引入新的思想,使用值对象,
public class User : AggregateRoot
{
public string Name { get; set; }//用户名
public UserName UserName { get; set; }//账号
public ProjectId ProjectId { get; set; }//项目id
public Image Img { get; set; }//图片
public PassWord PassWord { get; set; }//密码
public string Company { get; set; }//公司
}
上面是用户对象,里面用户账号有自己的业务逻辑,
密码也有自己的逻辑,将密码创建对象如下,
public class PassWord
{
public string Pwd { get; set; }
public PassWord()
{
}
public PassWord(string pwd)
{
if (pwd == null)
{
throw new ValidationException("密码不能为空");
}
//else if (pwd.Length < 6)
//{
// throw new ValidationException("密码长度应大于六");
//}
else
{
Pwd = DESHelper.Encrypt(pwd);
}
}
}
重写构造函数,里面写校验逻辑及密码加密
public User Login(string userName, PassWord passWord)
{
try
{
CjsiteUser user = context.Set<CjsiteUser>().Where(u => u.UserName == userName && u.PassWord == passWord.Pwd).Include(q => q.Project).Include(q => q.UserRoles).FirstOrDefault();
if (user == null)
{
throw new Exception("用户名或密码错误");
}
return autoMapperRepository.MapTo<CjsiteUser, User>(user);
}
catch (Exception ex)
{
throw new Exception(ex.Message);
}
}
在接口处传密码对象,实际业务代码不会带有任何校验逻辑,一个简单的封装对象,会对代码的整洁度有很大的提升,
03 计划
下篇写领域层实体对象的创建