领域驱动设计DDD：贫血模型和充血模型（比较重要）

学习这章的原因：实际工作项目中有些实体内写了方法有些只是纯粹的属性定义。正好领域驱动设计看到了贫血和充血模型。记录一下。

说实话虽然敏捷开发中大家不太关心你的功能设计背后的结构逻辑，但是本着对自己负责的态度，这部分需要特别注意。

- 普通程序员写hello word 直接print 
- 高级程序员写hello word 各种设计模式各种可拓展最后输出hello word 
- 技术专家写hello word ，直接打印hello word

 插一句：充血模型最大的困难是如何映射到数据库，这边需要看一下杨中科P165之后的教程。

Part6-10.NET的充血模型与贫血模型_哔哩哔哩_bilibili

1、贫血模型：一个类中只有属性或者成员变量，没有方法。

2、充血模型：一个类中既有属性、成员变量，也有方法。

举个🌰栗子：

需求：定义一个类保存用户的用户名、密码、积分；用户必须具有用户名；为了保证安全，密码采用密码的散列值保存；用户的初始积分为10分；每次登录成功奖励5个积分，每次登录失败扣3个积分。 

贫血模型

class User
{
	public string UserName { get; set; }//用户名
	public string PasswordHash { get; set; }//密码的散列值
	public int Credit { get; set; }//积分
}

功能实现

最大的缺点：领域知识/业务逻辑的高耦合！真TM的臃肿！

User u1 = new User(); u1.UserName = "yzk"; u1.Credit = 10;
u1.PasswordHash = HashHelper.Hash("123456");//计算密码的散列值
string pwd = Console.ReadLine();
if(HashHelper.Hash(pwd)==u1.PasswordHash)
{
    u1.Credit += 5;//登录增加5个积分
    Console.WriteLine("登录成功");
}
Else
{
    if (u1.Credit < 3)
         Console.WriteLine("积分不足，无法扣减");
    else
    {
        u1.Credit -= 3;//登录失败，则扣3个积分
        Console.WriteLine("登录成功");
    }
    Console.WriteLine("登录失败");
}

充血模型

不要用实现方式1，用2！

 意思是：参数名要和属性名保持一致！！！为什么！因为EF会跳过原本的get和set，去直接读属性！

 

 

class User
{//看这边傻逼
	public string UserName { get; init; } // init表示只能初始化时候设置     
	public int Credit { get; private set; }//private 无法在外部被修改 只能内部方法修改
	private string? passwordHash;
	public User(string userName)//通过构造的参数，确保创建时候name一定不为空
	{
		this.UserName = userName;
		this.Credit =10;
	}
	public void ChangePassword(string newValue)
	{
		if(newValue.Length<6)
		{
			throw new Exception("密码太短");
		}
		this.passwordHash =Hash(newValue);
	}
 
public bool CheckPassword(string password)
	{
		string hash = HashHelper.Hash(password);
		return passwordHash== hash;
	}
	public void DeductCredits(int delta)
	{
		if(delta<=0)
		{
			throw new Exception("额度不能为负值");
		}
		this.Credit -= delta;
	}
	public void AddCredits(int delta)
	{
		this.Credit += delta;
	}
}

 看一下 private string? passwordHash; 不属于 属性 的 成员变量 

 

 

 

功能实现

User u1 = new User("yzk");
u1.ChangePassword("123456");
string pwd = Console.ReadLine();
if (u1.CheckPassword(pwd))
{
    u1.AddCredits(5);
    Console.WriteLine("登录成功");
}
else
{
    Console.WriteLine("登录失败");
}

是所有的场景都适合使用充血模型吗？

使用充血模型也就是使用基于充血模型的DDD的开发模式，上文也一再强调，充血模型也是定义模式复杂，设计难等，代码开发量也许时其他模型的多，其主要原因还是设计起来难。那就是说如果我们设计一个很简单的业务逻辑，那我们还需要这么复杂的设计思想吗？ 并且这个业务在后续的迭代也不变复杂，那我个人认为我们就使用我们的基于贫血模型的面向过程的编程思想。简单的东西何必复杂化呢。

当然我们在进行一个复杂的业务场景，那就需要进行基于充血模型的DDD（领域驱动模型）开发模式了。其实DDD的开发模式也就是充分的遵循OOP发三大特性（或者四大特性，封装，继承，多态，（抽象）），如果是贫血模型的面向过程编程那到最后的结果就是点练成线，由线变成网，密密麻麻不可维护。所以说复杂业务逻辑基于充血模型的进行开发。但是也会是有问题的那就是类膨胀，一个类有很多代码。这个还是可以解决的，那就是通过设计模式，和业务逻辑细分进行解决。