core3商城实战（一）建模

一个校园商城项目（学生售卖二手物品与发布悬赏求助等，在线上确认校园内线下交易）

用户故事：发布商品或悬赏单，界面浏览最新商品与浏览分类下的商品，搜索商品，点击想要（加购物车），点击可接悬赏，点击进入第三方聊天界面，确认卖给哪一位想要者，线下交易结束双方确认完成交易，查看交易记录，查看发布的想要的商品列表，举报商品

管理员：审核发布信息和举报信息，审核通过才发布

建模不是模拟现实世界的人机交互流程，而是思考软件应该提供什么功能给用户用，满足业务需求。

划分子域为：商品子域，销售子域，用户子域，后台管理子域

划分上下文：

1，商品子域：普通商品上下文，悬赏求助上下文

以商品作为一个子域，通过商品能直接获得商品详情，获得相关需要的用户信息，以及销售状态），

2，销售子域：订单上下文，购物车上下文（因为感觉用户与购物车是一一对应的），

3，用户子域：用户上下文，

通过用户查询到用户的商品交易信息

4，后台管理上下文：管理上下文

划分聚合： 普通商品上下文（增{发布时}，删{交易结束}，改{修改发布商品信息}，查{界面浏览与搜索}）：

商品详情聚合：根-base（），实体（），值对象（）

public class Commodity: AggregateRoot
    {
        /// <summary>
        /// 商品详情(实体)
        /// </summary>
        public CommodityDetail CommodityDetail { get; private set; }
        /// <summary>
        /// 卖家基础信息（值）
        /// </summary>
        public CommoditySeller CommoditySeller { get; private set; }
        /// <summary>
        /// 想要人数（点击按钮后再从销售子域中获得具体想要者名单）
        /// </summary>
        public int wanter{ get; private set; }
    }

悬赏单上下文（增{发布时}，删{交易结束或者是自动超时}，改{修改发布商品信息}，查{界面浏览与搜索}）：

    public class Reward:AggregateRoot
    {
        /// <summary>
        /// 悬赏详情(实体)
        /// </summary>
        public CommodityDetail CommodityDetail { get; private set; }
        /// <summary>
        /// 卖家基础信息（值）
        /// </summary>
        public CommoditySeller CommoditySeller { get; private set; }
        /// <summary>
        /// 想要人数（点击按钮后再从销售子域中获得具体想要者名单）
        /// </summary>
        public int wanter { get; private set; }
    }

　　因为确实是非常相似的属性字段，所以与商品用的一样的实体，但是数据库里商品与悬赏是不能混合在一起的

订单上下文（）：

普通商品订单聚合（增{确认想要者时}，删{交易周期最后未双方确认}，改{交易周期内成功修改状态}，查{用户的历史记录，打开购物车时要先查询收藏商品有无卖出}）：

悬赏订单聚合（增{确认悬赏委派人}，删{交易周期最后未双方确认}，改{交易周期内成功修改状态}，查{用户的历史记录，打开购物车时要先查询收藏商品有无卖出}）：悬赏与普通商品的一大区别是常常存在时间短（比如带饭代拿快递）

购物车上下文（）：

购物车与任务聚合（普通商品与悬赏在数据库存储在一起，前端显示分开）：这个聚合到底需不需要单独拿出来还没想好

用户上下文（）：用户的购买和想要是私密的，卖与悬赏是公开的

用户聚合：用户的基本信息

后台管理上下文（）：

审核聚合：

举报聚合：

core3商城实战（一）建模

猜你喜欢