DDD领域驱动设计（领域，子域，界限上下文）_ddd领域上下界限-CSDN博客
目录
限界上下文就是“边界”，这与面向对象设计中的职责分配其实是同一道理。限界上下文的识别并不是一蹴而就的，需要演化和迭代。通过从业务边界到工作边界再到应用边界这三个层次抽丝剥茧，分别以不同的视角、不同的角色协作来运用对应的设计原则，会是一个可行的识别限界上下文的过程方法。整体过程如下图所示：
1从业务边界识别限界上下文
领域驱动设计围绕着“领域”来开展软件设计。在明确了系统的问题域和业务期望后，开发团队与领域专家经过充分地沟通与交流，可以梳理出主要的业务流程，这些业务流程体现了各种参与者在这个过程中通过业务活动共同协作，最终完成具有业务价值的领域功能。显然，业务流程结合了参与角色（Who）、业务活动（What）和业务价值（Why）。在业务流程的基础上，我们就可以抽象出不同的业务场景，这些业务场景又由多个业务活动组成，我们可以利用前面提到的领域场景分析方法剖析场景，以帮助我们识别业务活动，例如采用用例对场景进行分析，此时，一个业务活动实则就是一个用例。
例如，在针对一款文学阅读产品进行需求分析时，我们得到的业务流程为：
登录读者根据作品名或者作者名查询自己感兴趣的作品。在找到自己希望阅读的作品后，开始阅读。若阅读的作品为长篇，可以按照章节阅读，倘若作品为收费作品，则读者需要支付相应的费用，支付成功后可以阅读购买后的作品。在阅读时，倘若读者看到自己喜欢的句子或段落，可以作标记，也可以撰写读书笔记，还可以将自己喜欢的内容分享给别的朋友。读者可以对该作品和作者发表评论，关注自己喜欢的作品和作者。
注册用户可以申请成为驻站作者。审核通过的作者可以在创作平台上发布自己的作品，发布作品时，可以根据需要设置作品的章节。作者可以在发布作品之前预览作品，无论作品是否已经发布，都可以对作品的内容进行修改。作者可以设置自己的作品为收费或免费作品，并自行确定阅读作品所需的费用。如果是新作品发布，系统会发送消息通知该作者的关注者；若连载作品有新章节发布，系统会发送消息通知该作品的关注者。驻站作者可以为自己的作品建立作品读者群，读者可以申请加入该群，加入群的读者与作者可以在线实时聊天，也可以发送离线信息，或者将自己希望分享的内容发布到读者群中。注册用户之间可以发起一对一的私聊，也可以直接给注册用户发送私信。
通过对以上业务流程进行分析，结合在各个流程环节中需要的知识以及参与角色的不同，可以划分如下业务场景：
阅读作品创作作品支付社交消息通知注册与登录可以看到，业务流程是一个由多个用户角色参与的动态过程，而业务场景则是这些用户角色执行业务活动的静态上下文。从业务流程中抽象出来的业务场景可能是交叉重叠的，例如在读者阅读作品流程与作者创作流程中，都牵涉到支付场景的相关业务。
接下来，我们利用领域场景分析的用例分析方法剖析这些场景。我们往往通过参与者（Actor）来驱动对用例的识别，这些参与者恰好就是参与到场景业务活动的角色。根据用例描述出来的业务活动应该与统一语言一致，最好直接从统一语言中撷取。业务活动的描述应该精准地表达领域概念，且通过尽可能简洁的方式进行描述，通常格式为动宾形式。以阅读作品场景为例，可以包括如下业务活动：
查询作品
收藏作品
关注作者
浏览作品目录
阅读作品
标记作品内容
撰写读书笔记
评价作品
评价作者
分享选中的作品内容
分享作品链接购买作品
一旦准确地用统一语言描述出这些业务活动，我们就可以从如下两个方面（语义相关性功能相关性）识别业务边界，进而提炼出初步的限界上下文：
1.1语义相关性
从语义角度去分析业务活动的描述，倘若是相同的语义，可以作为归类的特征。语义相关性主要来自于描述业务活动的宾语。例如，前述业务活动中的查询作品、收藏作品、分享作品、阅读作品都具有“作品”的语义，基于这一特征，我们可以考虑将这些业务活动归为同一类。
识别语义相关性的前提是准确地使用统一语言描述业务活动。在描述时，应尽量避免使用“管理（manage）”或“维护（maintain）”等过于抽象的词语。抽象的词语容易让我们忽视隐藏的领域语言，缺少对领域的精确表达。例如，在文学阅读产品中，我们不能宽泛地写出“管理作品”、“管理作者
4008
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
