通知销售齐货
销售员
收货
仓管
DO
原型描述（Description）：对PPT的描述
报 价单
报 价单明细
商品价格数量
排产/生产管理
权限
销售订单
客户销售员日期备注
制作销售订单审核反审核删除作废一键采购（库存不足才生产采购）
Write Repository
价钱
供应商KPI看板
目标：完成领域模型
报检管理
MYSQL主
数据仓库封装
read cache
地点（Place）：配送单据就需要配送地址对象，否则就无法知道配送目的地。发布展会活动有地址对象，否则参展单位不知道在哪参会。明确需要地点信息的时标对象才需要地点对象。
参与方（Party）：订单就需要有客户，否则不知道是谁下单，客户对象就是参与方。支付单据就需要有客户和账户，客户对象和账户对象就是参与方。
第二是责任可追溯性：记录了管理者关注的信息。
委外订单
Read Repository
委外出库
从中抽象出这些人／事／物在事件中的角色
备料管理
write
会议以探讨领域事件开始从前往后依次梳理以确保领域中所有事件都能覆盖
领域对象
商品
客户：领域知识、业务难题
库存管理
Query
订单协同
time line
PMC
四色建模color modeling
DDDDomain-Drvice Destin领域驱动设计
寻找时标对象周围的人／事／物
QC
识别模型中可能的聚合及其聚合根
即时库存
事件风暴
采购订单
统一语言与建模领域
第一是事实不可变性：记录了过去某个时间点或时间段内发生的事实。
数量
客户
read db
参会人员：领域专家和软件开发人员
事实(fact）：是指那些已经发生过的事件。鉴于过去已经发生的事实不会发生改变，因此信息系统可以将这些事实以信息的形式存储到数据库中，即信息就是一组事实
销售发货
MYSQL从
研发：技术方案、设计细节
首先以满足管理的需要，寻找可追溯的事件
物品（Thing）：订单需要商品对象，否则无法说明买家到底购买了哪些商品。作为业务流程中核心步骤的被操作对象，并为时标对象提供必要信息，以便于后续信息追溯。
将模型分配到各个界限上下文中，构建上下文地图
API 调用者
供应商
时间原型（Moment-Interval）：表示在某个时刻或时间段内发生的某个活动
参与者/地点/物品原型（Party/Place/Thing）：表示事件相关的人物、地点、物品
商品分类
根据要追溯的事件，寻找足迹及其对应的时标对象
CQRSCommand Query RS
领域事件：即领域中发生的事实(fact)在真实世界中，当满足某个条件时，某个发起者会触发某个事件，做某个事情
ERP
事件即事实Event as Fact
对人／事／物的相关信息进行补充
制作报价单审核反审核删除作废
采购
建模过程
Redis
企业
项目组成员不断增加各种命令与事件进而思考与之相关的资源、外部系统与时间
角色原型(Role):表示某个(或事件)以某种角色参与某个事件
+ attribute1:type = defaultValue+ attribute2:type- attribute3:type
+ operation1(params):returnType- operation2(params)- operation3()
