一、前言
上篇中我们讲述了“把商品卖给用户”中的商品和用户的初步设计。现在把剩余的“卖”这个动作给做了。这里提醒一下，正常情况下，我们的每一步业务设计都需要和领域专家进行沟通，尽可能的符合通用语言的表述。这里的领域专家包括但不限于当前开发团队中对这块业务最了解的开发人员、系统实际的使用人等。
二、怎么卖
如果在没有结合当前上下文的情况下，用通用语言来表述，我们很容易把代码写成下面的这个样子（其中DomainRegistry只是一个简单的工厂，解耦应用层与其他具体实现的依赖，内部也可以使用IOC容器来实现）：
var user = DomainRegistry.UserService().GetUser(userId);
if (user == null)
{
return Result.Fail("未找到用户信息");
}
var product = DomainRegistry.ProductService().GetProduct(productId);
if (product == null)
{
return Result.Fail("未找到产品信息");
}
user.Buy(product, quantity);
return null;初步来看，好像很合理。这里表达出的是“用户购买了商品”这个语义。
然后继续往下写，我们会发现购买了之后应该怎么办呢，要把东西放到购物车啊。这里又出现了购物车，我认为购物车是我们销售子域中的一个核心概念，它也是整个用户购买过程中变化最频繁的一个对象。
我们来梳理一下，一个最简单的购物车至少包含哪些东西：
A.一个购物车必须是属于一个用户的。
B.一个购物车内必然包含购买的商品的相关信息。
首先我们思考一下如何在我们的购物车中表达出用户的概念，购物车需要知道用户的所有信息吗？
答案在大部分场景下应该是否定的，因为在用户挑选商品并加到购物车的这个过程中，整个购物车是不稳定的，那么其实在用户想要进行结算以前，我们只需要知道这个购物车是谁的，仅此而已。
那么这里我们已经排除了一种方式是购物车直接持有User的引用。所以说对于购物车来说，在我们排除为性能而进行数据冗余的情况下，我们只需要保持一个用户唯一标识的引用即可。
购物车明细和商品之间的关系也是一样，每次需要从远程上下中获取到最新的商品信息（如价格等），故也仅需保持一个唯一标识的引用。
结合上一篇讲的，我们目前已经出现了以下几个对象，见图1。
下面贴上购物车和购物车明细的简单实现。
public class Cart : Infrastructure.DomainCore.Aggregate
{
private readonly List<CartItem> _cartItems;
public Guid CartId { get; private set; }
public Guid UserId { get; private set; }
public DateTime LastChangeTime { get; private set; }
public Cart(Guid cartId, Guid userId, DateTime lastChangeTime)
{
if (cartId == default(Guid))
throw new ArgumentException("cartId 不能为default(Guid)", "cartId");
if (userId == default(Guid))
throw new ArgumentException("userId 不能为default(Guid)", "userId");
if (lastChangeTime == default(DateTime))
throw new ArgumentException("lastChangeTime 不能为default(DateTime)", "lastChangeTime");
this.CartId = cartId;
this.UserId = userId;
this.LastChangeTime = lastChangeTime;
this._cartItems = new List<CartItem>();
}
public void AddCartItem(CartItem cartItem)
{
var existedCartItem = this._cartItems.FirstOrDefault(ent => ent.ProductId == cartItem.ProductId);
if (existedCartItem == null)
{
this._cartItems.Add(cartItem);
}
else
{
existedCartItem.ModifyQuantity(existedCartItem.Quantity + cartItem.Quantity);
}
}
}public class CartItem : Infrastructure.DomainCore.Entity
{
public Guid ProductId { get; private set; }
public int Quantity { get; private set; }
public decimal Price { get; private set; }
public CartItem(Guid productId, int quantity, decimal price)
{
if (productId == default(Guid))
throw new ArgumentException("productId 不能为default(Guid)", "productId");
if (quantity <= 0)
throw new ArgumentException("quantity不能小于等于0", "quantity");
if (quantity < 0)
throw new ArgumentException("price不能小于0", "price");
this.ProductId = productId;
this.Quantity = quantity;
this.Price = price;
}
public void ModifyQuantity(int quantity)
{
this.Quantity = quantity;
}
}回到我们最上面的代码中的“user.Buy(product, quantity);” 的问题。
在DDD中主张的是清晰的业务边界，在这里，我们目前的定义导致的结果是User与Cart产生了强依赖，让User内部需要知道过多的Cart的细节，而这些是User不应该知道的。
这里还有一个问题是在领域对象内部去访问仓储（或者调用远程上下文的接口）来获取数据并不是一种提倡的方式，他会导致事务管理的混乱。
当然有人会说，把Cart作为一个参数传进来，这看上去是个好主意，解决了在领域对象内部访问仓储的问题，然而看一下接口的定义，用户购买商品和购物车？还是用户购买商品并且放入到购物车？
这样来看这个方法做的事情似乎过多了，违背了单一职责原则。
其实在大部分语义中使用“用户”作为一个主体对象，看上去也都还挺合理的，然而细细的去思考当前上下文（系统）的核心价值，会发现“用户”有时并不是核心，当然比如是一个CRM系统的话核心即是“用户”。
总结一下这种方式的缺点：
A.领域对象之间的耦合过高，项目中的对象容易形成蜘蛛网结构的引用关系。
B.需要在领域对象内部调用仓储，不利于最小化事务管理。
C.无法清晰的表达出通用语言的概念。
重新思考这个方法。“购买”这个概念更合理的描述是在销售过程中所发生的一个操作过程。
在我们电商行业下，可以表述为“用户购买了商品”和“商品被加入购物车”。这时候需要领域服务出场了，由它来表达出“用户购买商品”这个概念最为合适不过了。其实就是把应用层的代码搬过来了，以下是对应的代码：
public class UserBuyProductDomainService
{
public CartItem UserBuyProduct(Guid userId, Guid productId, int quantity)
{
var user = DomainRegistry.UserService().GetUser(userId);
if (user == null)
{
throw new ApplicationException("未能获取用户信息！");
}
var product = DomainRegistry.ProductService().GetProduct(productId);
if (product == null)
{
throw new ApplicationException("未能获取产品信息！");
}
return new CartItem(productId, quantity, product.SalePrice);
}
}
三、领域服务的使用
领域中的服务表示一个无状态的操作，它用于实现特定于某个领域的任务。当某个操作不适合放在聚合和值对象上时，最好的方式便是使用领域服务了。
1.列举几个领域服务适用场景
A.执行一个显著的业务操作过程。
B.对领域对象进行转换。
C.以多个领域对象作为输入进行计算，结果产生一个值对象。
D.隐藏技术细节，如持久化与缓存之间的依存关系。
2.不要把领域服务作为“银弹”。过多的非必要的领域服务会使项目从面向对象变成面向过程，导致贫血模型的产生。
3.可以不给领域服务创建接口，如果需要创建则需要放到相关聚合、实体、值对象的同一个包（文件夹）中。服务的实现可以不仅限于存在单个项目中。
四、回到现实
按照这样设计之后我们的应用层代码变为：
var cartItem = _userBuyProductDomainService.UserBuyProduct(userId, productId, quantity);
var cart = DomainRegistry.CartRepository().GetOfUserId(userId);
if (cart == null)
{
cart = new Cart(DomainRegistry.CartRepository().NextIdentity(), userId, DateTime.Now);
}
cart.AddCartItem(cartItem);
DomainRegistry.CartRepository().Save(cart);这里的第5行用到了一个仓储（资源库）CartRepository，仓储算是DDD中比较好理解的概念。
在DDD中仓储的基本思想是用面向集合的方式来体现，也就是相当于你在和一个List做操作，所以切记不能把任何的业务信息泄露到仓储层去，它仅用于数据的存储。
仓储的普遍使用方式如下：
A.包含保存、删除、指定条件的查询（当然在大型项目中可以考虑采用CQSR来做，把查询和数据操作分离）。
B.只为聚合创建资源库
C.通常资源库与聚合式 1对1的关系，然而有时，当2个或者多个聚合位于同一个对象层级中时，它们可以共享同一个资源库。
D.资源库的接口定义和聚合放在相同的模块中，实现类放在另外的包中（为了隐藏对象存储的细节）。
回到代码中来，标红的那部分也可以用一个领域服务来实现，隐藏“如果一个用户没有购物车的情况下新建一个购物车”的业务细节。
public class GetUserCartDomainService
{
public Cart GetUserCart(Guid userId)
{
var cart = DomainRegistry.CartRepository().GetOfUserId(userId);
if (cart == null)
{
cart = new Cart(DomainRegistry.CartRepository().NextIdentity(), userId, DateTime.Now);
DomainRegistry.CartRepository().Save(cart);
}
return cart;
}
}这样应用层就真正变成了一个讲故事的人，清晰的表达出了“用户购买商品的整个过程”，把商品购物车的商品转换成购物车明细 –> 获取用户的购物车 –> 添加购物车明细到购物车中 –> 保存购物车。
public Result Buy(Guid userId, Guid productId, int quantity)
{
var cartItem = _userBuyProductDomainService.UserBuyProduct(userId, productId, quantity);
var cart = _getUserCartDomainService.GetUserCart(userId);
cart.AddCartItem(cartItem);
DomainRegistry.CartRepository().Save(cart);
return Result.Success();
}
五、结语
这是最简单的购买流程，后续我们会慢慢充实整个购买的业务，包括会员价、促销等等。
我还是保持每一篇内容的简短，这样可以最大限度地保证不被其他日常琐事影响每周的更新计划。希望大家谅解：）
本文的源码地址：https://github.com/ZacharyFan/DDDDemo/tree/Demo4。
原创文章，转载请注明本文链接: https://zacharyfan.com/archives/134.html
关于作者：张帆（Zachary，个人微信号：Zachary-ZF）。坚持用心打磨每一篇高质量原创。欢迎扫描二维码~
定期发表原创内容：架构设计丨分布式系统丨产品丨运营丨一些思考。
如果你是初级程序员，想提升但不知道如何下手。又或者做程序员多年，陷入了一些瓶颈想拓宽一下视野。欢迎关注我的公众号「跨界架构师」，回复「技术」，送你一份我长期收集和整理的思维导图。
如果你是运营，面对不断变化的市场束手无策。又或者想了解主流的运营策略，以丰富自己的“仓库”。欢迎关注我的公众号「跨界架构师」，回复「运营」，送你一份我长期收集和整理的思维导图。
