如何一步一步用DDD设计一个电商网站(四)—— 把商品卖给用户

一、前言

上篇中我们讲述了“把商品卖给用户”中的商品和用户的初步设计。现在把剩余的“卖”这个动作给做了。这里提醒一下,正常情况下,我们的每一步业务设计都需要和领域专家进行沟通,尽可能的符合通用语言的表述。这里的领域专家包括但不限于当前开发团队中对这块业务最了解的开发人员、系统实际的使用人等。

二、怎么卖

如果在没有结合当前上下文的情况下,用通用语言来表述,我们很容易把代码写成下面的这个样子(其中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,点击图片查看原图】。

【图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.可以不给领域服务创建接口,如果需要创建则需要放到相关聚合、实体、值对象的同一个包(文件夹)中。服务的实现可以不仅限于存在单个项目中。

四、回到现实

按照这样设计之后我们的应用层代码变为:

1             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             }
7             cart.AddCartItem(cartItem);
8             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_Fan 出处:http://www.cnblogs.com/Zachary-Fan/p/6041374.html

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏诸葛青云的专栏

在微信好友信息抓取这一块,这才是最好的python分析技巧!

早些日子有人问我我的微信里面有一共多少朋友,我就随后拉倒了通讯录最下面就找到了微信一共有多少位好友。然后他又问我,这里面你认识多少人?

5054
来自专栏Python中文社区

我是如何使用Python来自动化我的婚礼的

譯 文 ❈ 原作者:Thomas Curtis 译者:ictar Github:https://github.com/ictar ❈ 2016年9月3日,对世...

2098
来自专栏FreeBuf

极客DIY:童年的掌上游戏机

写在前面 小伙伴们,还记得过去的掌上游戏机吗?一名网友wermy在YouTube上面上传了一个DIY掌上游戏机的视频,下面就一起来怀念一下童年的见闻。 game...

2436
来自专栏程序人生

如何阅读一份代码?

上文谈到了像读书一样阅读源码的重要性,今天谈谈如何阅读一份代码。我所谓的一份代码,其范围可能从几千行到数万行,有时甚至可多达数十万行。这些代码作为一个有机体,共...

3777
来自专栏Web行业观察

Qt widget vs Qt Quick

并不是说web语言不好, 我很喜欢web, 从一开始学习html到后来入坑nodejs可以说web领域给我带来了很多的见识同时还payed my bil...

1.2K1
来自专栏BestSDK

一文看懂 iOS 11所有新功能:文件管理器、多任务处理、全新文件 App等

全新文件 App 通过这个App,可以把各类文件汇集在一起,浏览、搜索和整理文件。用户最近使用过的各种文件都会在一个专属的位置,以方便查看。除了 iPad 上的...

3358
来自专栏数据小魔方

用优雅的配色来缔造图表专业主义~

前天刚恢复状态的小魔方,今天又粗现啦~ 很多小伙伴儿问我为啥最近老是偷懒,其实是因为上周期中课程论文缠身(毕竟拖延症嘛总得拖到deadline否则绝不开工~_~...

2604
来自专栏钱曙光的专栏

一周极客热文:微软将推新编程语言M#:系统编程级别的C#

据国外媒体VB报道,微软正在开发一款新的编程语言:M# 。它在C#的基础上添加了系统编程特性,可用来构建各种类型的应用,尤其是云计算应用。 微软员工Joe Du...

2706
来自专栏刺客博客

SS详解(一):原理

4.9K4
来自专栏SDNLAB

超大规模数据中心网络

一、计算模式的演进 图 1 计算模式的演进 计算纪年: 1、大型机时代:20世纪60~70年代,计算机体积大、价格高,支持成百上千用户同时操作。 2、个人电...

4416

扫码关注云+社区

领取腾讯云代金券