我所在学校部门的一个校园商城项目（学生售卖二手物品与发布悬赏求助等，在线上确认，校园内线下交易）
我们使用DDD的软件开发方法，这是我们进入编程世界上手的第二个项目，从创建仓库到现在已经过去二十多天，进度大概才五分之一到四分之一，因此现在看《实现领域驱动设计》第一章第一句“你期待从DDD中得到什么？首先DDD不应该是一个仪式性的过程，跟不应该成为你项目的阻碍”，对我无疑是暴击，好像这20天做的事恰恰相反，后悔没有早一点掀开书看看。
不过既然已经深入到DDD这些天，很难放弃我们会将项目写完并上线，在这里进行一个回顾和总结（小小的学生团队，就自己当领域专家吧）
（ps:以下的DDD尝试可能都很多重大纰漏，请大佬能帮我提出，感激不尽）
首先粗略的整理项目用户故事
用户故事：发布商品或悬赏单，界面浏览最新商品与浏览分类下的商品，搜索商品，点击想要（加购物车），点击可接悬赏，点击进入第三方聊天界面，确认卖给哪一位想要者，线下交易结束双方确认完成交易，查看交易记录，查看发布的想要的商品列表，举报商品
管理员：审核发布信息和举报信息，审核通过才发布
（建模不是模拟现实世界的人机交互流程，而是思考软件应该提供什么功能给用户用，满足业务需求。）
构建设计框图
（做流程图不是设计，是讨论模型的一种方式，在DDD中，设计就是代码，代码就是设计）
（前三张图部分地方忘了加事件溯源不过代码中会体现的）
并没有展示全部的业务流程图，其实以上就是和领域专家建立通用语言的理想化步骤吧，但是后期上手代码的话，还是不可避免的发生变化，这些文档都会过时
领域建模
最开始我们将整个项目划分为商品子域，销售子域，用户子域，后台管理子域，以及比较小的举报子域
后来考虑审核功能应该是商品上下文的领域事件，因为我这个功能的实现还是围绕着商品的正删改查
然后管理域中的管理员与超级管理员的更替的业务应该是属于用户上下文的领域事件吧，这样我们目前定下域为商品子域，销售子域（核心域），用户子域以及比较小的举报子域（通用）
其实目前感觉自己真的消化不了DDD的战术建模，因为进入时间太短，在此之前并没有使用开发方法的经验（无论敏捷还是DDD），最后定下的模型可能也是不合理，不过继续做吧
划分限界上下文
1，商品子域：商品
以商品作为一个子域，通过商品能直接获得商品详情，获得相关需要的用户信息，以及销售状态），
2，销售子域：订单上下文
3，用户子域：用户上下文，
4，举报通用子域：举报上下文
关于搭建这个模型我们最大的不足还是没有泾渭分明的，完善的把每一个限界上下文的领域服务与领域事件勾勒出来，也并没有创立上下文映射图
不过好像并不太影响我们业务的实现，但希望以后能更关注这方面
我们最致命的缺点我感觉是项目中建立的还是贫血模型，这个是想在之后代码的编写过程中进行完善的
其中我们使用CQRS读写分离，es事件溯源，感谢（老张的哲学）的博客，优秀的博主
（3月28更新：我们的领域模型好像太接近数据库实体了，好像模型并不是面向业务进行的划分，还是面向的数据库，唉，现在感觉领域模型的意义就是以不变应万变吧，Dto和数据库实体从领域模型中映射衍生，并且并不会干扰，领域模型还在数据的处理和中转中出力，不过我们项目的业务比较简单，大多是中转作用）