关于一次领域开发的复盘

DDD领域设计的好处不是个人认知而是众所周知：统一业务概念促进业务建模、驱动微服务架构、增加代码服务率可读性等等。之前用DDD做过一个商城商品管理的后端开发。曾经因为变更需求推翻过初期的实现，想想也是心塞。复盘一下，加深以下对领域设计的认知，也避免出现同样的瞬时认知误差导致操作失误。
原始确认下来的对商品管理以及库存管理的认知，是以下图的黑色字体部分。商品部分无非就是基础信息的管理以及状态管理；而库存管理就是要注意的处理入库、出库、预占、流水还要注意以下并发操作。so easy，不用分析画图了，就两个简单域，建库，开发。
然而过了一周后，实现了一半后，“甲方”说我的商品有很多销售条件啊，属性啊，层次级别啊......要放在商品信息中。【附：以下图的红色部分就是改动】经过一番理论，这些东西属于商品域的被确认下来，我顿时一脸懵圈。WHAT......开发时间用掉一半的我有点紧迫感，基于这些东西属于商品域 开始胡思乱想了（其实要放在商品信息中这句话挺误导的）。开始对商品进行拆表，重新分析库存还是当初我认识的那个库存吗（因为销售属性的加入，商品上下架状态移到了库存上面）。数据库结构一变，思维惯式开始觉得以前的设计都是错的，要推翻重写。就像新增商品，就不是新增商品基础属性，还要新增销售属性（其实这时候已经让领域能力层和应用层腐蚀掉了）。其实，如果当时有时间把图画一画分析一下，会发现，其实商品基础信息还是那些基础信息，而销售属性，他们是属于商品域下的另外一个子域，而完整的商品，是几个子域的聚合，这个聚合就是一个业务商品的概念。代码根本不用推翻，要重新思考的增加应用服务的业务线。

总结一下tips避免再次踩坑To myself把：
（1）既然是实际线下业务的开发，不要以为业务实现简单就不分析做概要设计，因为你无法预知市场的变动是不是如你想象的简单。有时候前期的设计不是为了本次的开发，而是为了下一次需求变更迭代会议的风险评估和工时预测。
（2）开始开发了，就要确保领域不被侵入，或者说领域边界逐渐模糊。像上面加入的商品销售属性，他是商品域的，但是他区分于基础信息子域，他跟其他子域合做才能构成一个完整的业务概念。不要模糊。
（3）讨论需求变更的时候忌抓住一个观点变是非，忌思维定势，可以转变一下观念，比如认知我们的都没错，是边界都模糊了吗？
（4）此外，多表分页查询除了hibernate、mybatis写多表关联查询语句、以及前端异步请求信息外[/思考]还有啥攻略