            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，点击图片查看原图】。

　　　　　　　　　　　　　　　　　　　　　　　【图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 <= )

                throw new ArgumentException("quantity不能小于等于0", "quantity");

            if (quantity < )

                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);

2             var cart = DomainRegistry.CartRepository().GetOfUserId(userId);

3             if (cart == null)

4             {

5                 cart = new Cart(DomainRegistry.CartRepository().NextIdentity(), userId, DateTime.Now);

6             }

             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。

作者：Zachary
出处：https://zacharyfan.com/archives/134.html

▶关于作者：张帆（Zachary，个人微信号：Zachary-ZF）。坚持用心打磨每一篇高质量原创。欢迎扫描右侧的二维码~。

定期发表原创内容：架构设计丨分布式系统丨产品丨运营丨一些思考。

如果你是初级程序员，想提升但不知道如何下手。又或者做程序员多年，陷入了一些瓶颈想拓宽一下视野。欢迎关注我的公众号「跨界架构师」，回复「技术」，送你一份我长期收集和整理的思维导图。

如果你是运营，面对不断变化的市场束手无策。又或者想了解主流的运营策略，以丰富自己的“仓库”。欢迎关注我的公众号「跨界架构师」，回复「运营」，送你一份我长期收集和整理的思维导图。

码农公寓

一、前言

二、怎么卖

三、领域服务的使用

四、回到现实

五、结语

相关文章