领域驱动设计统一过程交付物

梳理问题空间的业务需求，获得用泳道图表现的业务流程：,,根据业务服务的定义分析业务流程，识别出业务服务，并以业务服务图（参考用例图）形式表示：,,说明：如果采用敏捷方式管理需求，可以将业务服务作为用户故事的子任务，它不包括前端的交互设计和开发内容。,如果需要进一步细化业务服务，则需要按照如下格式编写业务服务规约：,,编写业务服务规约时，需要遵循统一语言。,以上内容，可以构成目标系统的需求规格说明书。,系统上下文用于呈现目标系统的系统边界，明确目标系统与角色、伴生系统之间的关系。可以通过改进的系统上下文图来表示：,,改进的系统上下文有效地利用了四个方位：,运用服务风暴法，识别限界上下文，建立业务服务与限界上下文的映射关系，并以下图形式呈现出来：,,图中的菱形代表限界上下文，椭圆形代表业务服务。,针对每一个业务服务，通过业务服务规约绘制服务序列图，以确定限界上下文之间的协作关系，并驱动出每个限界上下文的服务契约。绘制服务序列图时，根据业务服务规约“成功场景”部分的流程，确定每个流程步骤需要的领域知识和领域职责应该由哪一个限界上下文负责。服务序列图如下所示：,,通过服务序列图，既可以明确限界上下文之间的关系，又可以驱动出每个限界上下文包括伴生系统的服务契约（API），同时还能够确定协作模式，包括客户方-供应方模式和发布者-订阅者模式。其中，查询和命令方式属于客户方-供应方模式，事件方式属于发布者-订阅者模式。服务契约可以通过下表格式表示：,,服务契约的API定义也可以在Swagger中维护。,最后，可以通过如下图示表示限界上下文：,,与改进的系统上下文图相似，限界上下文图也有效地利用了四个方位：,限界上下文内部可以呈现属于当前限界上下文领域模型的聚合，如果还未开展领域建模，可以为空。,限界上下文的内部应遵循如下图所示的菱形对称架构：,,菱形对称架构的核心思想：,在目标系统层面上，需要将各个限界上下文组织在如下图所示的系统分层架构中：,,代码模型,遵循菱形对称架构，一个完整的代码模型如下所示：,boundedcontext,resource,controller,provider,subscriber,entity,valueobject,domainservice,repository,client,publisher,repository,client,publisher,以上内容构成了目标系统的架构设计文档。,领域建模阶段是通过对业务服务规约进行领域分析建模开始的。领域分析建模与具体的建模技术和设计方法没有任何关系，只是从业务的角度通过提取领域概念获得最终的领域分析模型。该方法为快速建模法，得到的模型如下图所示：,,图中的灰色领域概念是通过动词建模法获得的。整个领域分析模型需要分配给对应的限界上下文。,领域设计建模从下图所示的领域分析模型开始：,,识别实体和值对象：,,确定实体之间的关系：,,根据实体关系的强弱划定聚合的边界，获得以聚合为中心的领域设计模型：,,获得动态设计模型的过程如下图所示：,,分析业务服务，获得如下所示的业务服务规约：,服务编号：033,服务名：报名活动,服务描述：    ,作为报名人    ,我想要报名活动    ,以便于预留活动报名资格,触发事件：    ,报名人选择自己想要报名的活动，点击“报名”按钮,基本流程：,替换流程：,验收标准：        ,根据业务服务规约获得如下所示的任务树：,分配职责给对应的角色构造型，形成序列图脚本：,领域建模阶段输出的静态领域设计模型与动态领域设计模型共同组成限界上下文的设计文档。