[{"data":1,"prerenderedAt":518},["ShallowReactive",2],{"blog-ddd-strategic-design":3},{"id":4,"title":5,"body":6,"category":504,"date":505,"description":493,"extension":506,"meta":507,"navigation":508,"path":509,"seo":510,"series":511,"seriesOrder":494,"stem":512,"tags":513,"__hash__":517},"blog\u002Fblog\u002Fddd-strategic-design.md","DDD 实战（二）：战略设计，从业务语言到限界上下文",{"type":7,"value":8,"toc":492},"minimark",[9,13,28,31,34,56,59,64,67,70,73,76,84,88,91,98,104,110,113,130,133,150,153,167,170,174,177,180,183,197,200,214,217,231,234,248,256,260,263,271,277,280,287,291,294,297,329,332,354,357,361,364,367,390,393,396,399,403,406,409,412,415,418,421,424,444,447,451,454,480,483,486],[10,11,5],"h1",{"id":12},"ddd-实战二战略设计从业务语言到限界上下文",[14,15,16],"blockquote",{},[17,18,19,20,27],"p",{},"推荐 ",[21,22,26],"a",{"href":23,"rel":24},"https:\u002F\u002Fbewild.ai?code=BYZDOTME",[25],"nofollow","BeWild"," 代充 Codex ，工作猛猛提效。",[17,29,30],{},"DDD 的战略设计，解决的是大系统的结构问题。",[17,32,33],{},"它不急着问类怎么写、表怎么建、Repository 放在哪里，而是先问几个更上游的问题：",[35,36,37,41,44,47,50,53],"ul",{},[38,39,40],"li",{},"这个业务到底由哪些领域构成？",[38,42,43],{},"哪些能力决定产品竞争力？",[38,45,46],{},"哪些能力只是支撑主业务运行？",[38,48,49],{},"哪些能力可以复用成熟方案？",[38,51,52],{},"哪些概念必须使用同一套模型？",[38,54,55],{},"哪些概念虽然名字一样，但在不同语境下含义不同？",[17,57,58],{},"这些问题没有回答清楚，后面的战术设计和代码分层都会变形。",[60,61,63],"h2",{"id":62},"_1-领域业务问题的边界","1. 领域：业务问题的边界",[17,65,66],{},"领域可以先粗略理解为“系统要解决的业务问题空间”。",[17,68,69],{},"电商有交易领域、支付领域、履约领域、库存领域、营销领域。支付系统有收银台、支付单、渠道路由、清结算、账务、风控。协同办公 IM 有账号、组织、关系、群组、消息、通知、工作台、审批、开放平台、搜索、安全治理。",[17,71,72],{},"注意，领域不是技术模块。",[17,74,75],{},"“MySQL”“Redis”“MQ”“HTTP 网关”不是领域，它们是实现手段。“用户表”“消息表”“群表”也不是天然领域，它们只是某个模型的持久化形态。",[17,77,78,79],{},"领域划分应该先从业务能力出发，再落到系统边界。Microsoft 的领域分析文档也强调，微服务边界应围绕业务能力，而不是围绕数据访问、消息等水平技术层。",[21,80,83],{"href":81,"rel":82},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Farchitecture\u002Fmicroservices\u002Fmodel\u002Fdomain-analysis",[25],"Microsoft: Domain analysis for microservices",[60,85,87],{"id":86},"_2-子域不是所有业务都同样重要","2. 子域：不是所有业务都同样重要",[17,89,90],{},"一个大领域可以继续拆成多个子域。DDD 通常把子域分成三类：核心域、支撑域、通用域。",[17,92,93,97],{},[94,95,96],"strong",{},"核心域"," 是产品差异化和竞争力所在。它值得投入最强的建模精力，不能轻易外包给通用方案。",[17,99,100,103],{},[94,101,102],{},"支撑域"," 是业务运行必需，但不是核心竞争力。它通常需要定制开发，但建模深度和投入优先级低于核心域。",[17,105,106,109],{},[94,107,108],{},"通用域"," 是行业里已经有成熟解法的能力。能买就买，能复用就复用，不要把团队最宝贵的注意力耗在这里。",[17,111,112],{},"以协同办公 IM 为例，如果我们把它定位成“企业沟通协作平台”，那核心域可能包括：",[35,114,115,118,121,124,127],{},[38,116,117],{},"会话与消息。",[38,119,120],{},"组织身份与通讯录。",[38,122,123],{},"群组协作。",[38,125,126],{},"开放平台生态。",[38,128,129],{},"安全治理和权限体系。",[17,131,132],{},"支撑域可能包括：",[35,134,135,138,141,144,147],{},[38,136,137],{},"通知。",[38,139,140],{},"搜索。",[38,142,143],{},"日程。",[38,145,146],{},"审批。",[38,148,149],{},"工作台应用入口。",[17,151,152],{},"通用域可能包括：",[35,154,155,158,161,164],{},[38,156,157],{},"短信验证码。",[38,159,160],{},"基础文件预览。",[38,162,163],{},"通用对象存储。",[38,165,166],{},"第三方登录协议适配。",[17,168,169],{},"这个分类不是永久不变的。如果产品战略变了，子域分类也会变。比如一个普通 IM 产品里，审批可能只是支撑域；但如果产品转向深度 OA 协同，审批和流程编排就可能上升为核心域。",[60,171,173],{"id":172},"_3-统一语言模型先进入语言再进入代码","3. 统一语言：模型先进入语言，再进入代码",[17,175,176],{},"DDD 非常重视统一语言。所谓统一语言，不是写一份术语表放在文档里，而是让业务、产品、开发、测试在同一个上下文里使用同一套词，并把这套词落实到代码、接口、事件、表名和文档中。",[17,178,179],{},"协同办公 IM 里，“用户”这个词就应该被拆开看。",[17,181,182],{},"在账号上下文里，我们可能说：",[35,184,185,188,191,194],{},[38,186,187],{},"Account：一个可登录账号。",[38,189,190],{},"Credential：账号凭证。",[38,192,193],{},"Device：登录设备。",[38,195,196],{},"LoginSession：登录会话。",[17,198,199],{},"在组织上下文里，我们说：",[35,201,202,205,208,211],{},[38,203,204],{},"Tenant：企业或租户。",[38,206,207],{},"Department：部门。",[38,209,210],{},"Member：组织成员。",[38,212,213],{},"OrgRole：组织角色。",[17,215,216],{},"在关系上下文里，我们说：",[35,218,219,222,225,228],{},[38,220,221],{},"ContactRelation：联系人关系。",[38,223,224],{},"FriendRequest：好友申请。",[38,226,227],{},"BlockRelation：拉黑关系。",[38,229,230],{},"ExternalContact：外部联系人。",[17,232,233],{},"在群组上下文里，我们说：",[35,235,236,239,242,245],{},[38,237,238],{},"Group：群。",[38,240,241],{},"GroupMember：群成员。",[38,243,244],{},"GroupRole：群角色。",[38,246,247],{},"GroupPolicy：群治理规则。",[17,249,250,251,255],{},"这些词背后都是“人”，但它们不是同一个模型。强行复用一个 ",[252,253,254],"code",{},"User","，会让语言变模糊，也会让代码变脆。",[60,257,259],{"id":258},"_4-限界上下文模型有效的范围","4. 限界上下文：模型有效的范围",[17,261,262],{},"限界上下文是战略设计里最关键的概念之一。",[17,264,265,266],{},"Martin Fowler 对 Bounded Context 的解释是：一个模型只在特定上下文内保持一致和明确，不同上下文之间需要显式映射。",[21,267,270],{"href":268,"rel":269},"https:\u002F\u002Fmartinfowler.com\u002Fbliki\u002FBoundedContext.html",[25],"Martin Fowler: Bounded Context",[17,272,273,274],{},"换句话说，限界上下文回答的是：",[94,275,276],{},"这套模型在哪个范围内成立？",[17,278,279],{},"比如“成员”在组织上下文里，关注的是企业、部门、岗位、入职状态、组织角色、字段可见性。在群组上下文里，关注的是群昵称、群角色、入群方式、禁言状态、最后阅读位置。它们都可以关联到同一个现实中的人，但模型关注点完全不同。",[17,281,282,283,286],{},"如果两个上下文都叫 ",[252,284,285],{},"Member","，也可以接受，只要它们处在不同包、不同服务或不同模块边界内，并且交互时使用明确的防腐层或 DTO。问题不在于重名，而在于没有边界。",[60,288,290],{"id":289},"_5-上下文映射边界之间怎么协作","5. 上下文映射：边界之间怎么协作",[17,292,293],{},"限界上下文不是孤岛。复杂系统的关键恰恰在于上下文之间如何协作。",[17,295,296],{},"DDD 里常见的上下文关系包括：",[35,298,299,305,311,317,323],{},[38,300,301,304],{},[94,302,303],{},"客户方\u002F供应方","：一个上下文依赖另一个上下文提供能力。",[38,306,307,310],{},[94,308,309],{},"开放主机服务","：上游上下文用稳定 API 暴露能力。",[38,312,313,316],{},[94,314,315],{},"发布语言","：上下文之间使用约定好的接口、事件或协议沟通。",[38,318,319,322],{},[94,320,321],{},"防腐层","：下游上下文通过转换层隔离上游模型。",[38,324,325,328],{},[94,326,327],{},"各行其是","：两个上下文没有必要集成，保持独立演进。",[17,330,331],{},"协同办公 IM 中，组织上下文和消息上下文就不应该共享组织表。更合理的方式是：",[333,334,335,338,345,348,351],"ol",{},[38,336,337],{},"组织上下文负责组织成员事实。",[38,339,340,341,344],{},"组织上下文发布 ",[252,342,343],{},"OrganizationMemberChanged"," 事件。",[38,346,347],{},"消息上下文维护自己需要的成员快照或权限缓存。",[38,349,350],{},"消息发送时只依赖消息上下文内的发送规则。",[38,352,353],{},"权限强校验需要调用组织上下文时，通过明确接口完成。",[17,355,356],{},"这样做牺牲了一些实时一致性和实现简单性，但换来了模型边界和故障隔离。组织结构频繁同步时，不会把消息主链路拖死。",[60,358,360],{"id":359},"_6-核心域支撑域通用域如何影响投入","6. 核心域、支撑域、通用域如何影响投入",[17,362,363],{},"DDD 的一个重要价值，是帮团队决定“哪里值得复杂，哪里必须简单”。",[17,365,366],{},"如果会话与消息是核心域，就值得认真设计：",[35,368,369,372,375,378,381,384,387],{},[38,370,371],{},"消息 ID 与幂等。",[38,373,374],{},"消息状态机。",[38,376,377],{},"已读未读模型。",[38,379,380],{},"撤回、编辑、引用、转发规则。",[38,382,383],{},"大群扇出策略。",[38,385,386],{},"多端同步游标。",[38,388,389],{},"加密消息和普通消息的差异。",[17,391,392],{},"如果短信验证码是通用域，就不应该投入大量模型设计。封装一个清晰的 provider 接口，接入供应商即可。",[17,394,395],{},"如果审批是支撑域，但未来可能成为核心域，那早期可以先保持模块化边界，不必马上设计成独立流程引擎。等审批规则、表单编排、自动化流转真正成为产品竞争力，再提升建模投入。",[17,397,398],{},"战略设计的价值就在这里：它不是让所有模块都“DDD 化”，而是让团队知道哪些地方必须精细建模，哪些地方保持朴素即可。",[60,400,402],{"id":401},"_7-没有标准答案但有判断依据","7. 没有标准答案，但有判断依据",[17,404,405],{},"领域划分没有唯一标准答案。尤其在账号、组织、关系、群组这些边界上，不同团队很容易给出不同方案，而且各有道理。",[17,407,408],{},"比如好友关系应该放在账号域吗？",[17,410,411],{},"如果产品很简单，好友只是账号之间的一个双向关系，放在账号模块里可以接受。这样实现快、调用少、事务简单。",[17,413,414],{},"但如果好友关系逐渐演化出申请、备注、分组、黑名单、外部联系人、客户关系、关系权限、隐私设置，它就不再只是账号的附属字段，而是一个独立关系上下文。",[17,416,417],{},"再比如群聊应该属于消息域吗？",[17,419,420],{},"如果群只是消息投递目标，把群放在消息模块里似乎合理。但如果群有群主、管理员、入群审批、群公告、群禁言、群机器人、群文件、群权限，群组模型就应该独立出来，消息域只消费“可发送到某个会话”的结果。",[17,422,423],{},"所以判断一个边界是否合理，要看：",[35,425,426,429,432,435,438,441],{},[38,427,428],{},"业务语言是否清晰。",[38,430,431],{},"变化是否能局部化。",[38,433,434],{},"一致性边界是否自然。",[38,436,437],{},"团队职责是否匹配。",[38,439,440],{},"部署和调用成本是否可接受。",[38,442,443],{},"未来演进时是否有可迁移路径。",[17,445,446],{},"DDD 的严肃性不是“切得最细”，而是“切得有理由”。",[60,448,450],{"id":449},"_8-战略设计的产出应该是什么","8. 战略设计的产出应该是什么",[17,452,453],{},"一次有价值的战略设计，至少应该产出这些东西：",[35,455,456,459,462,465,468,471,474,477],{},[38,457,458],{},"领域全景图。",[38,460,461],{},"子域分类：核心域、支撑域、通用域。",[38,463,464],{},"限界上下文列表。",[38,466,467],{},"每个上下文的职责、不应承担的职责。",[38,469,470],{},"上下文之间的关系图。",[38,472,473],{},"关键领域事件。",[38,475,476],{},"数据所有权说明。",[38,478,479],{},"当前阶段的拆分优先级。",[17,481,482],{},"这些产出不一定都要画成正式 UML。白板、表格、Markdown、Mermaid 图都可以。关键是团队能围绕这些产出讨论，并且在代码和部署里逐步兑现。",[17,484,485],{},"下一篇我们进入战术设计，看实体、值对象、聚合根、领域服务和领域事件如何把战略边界落到代码模型中。",[17,487,488],{},[21,489,491],{"href":490},"\u002Fblog\u002F","返回博客列表",{"title":493,"searchDepth":494,"depth":494,"links":495},"",2,[496,497,498,499,500,501,502,503],{"id":62,"depth":494,"text":63},{"id":86,"depth":494,"text":87},{"id":172,"depth":494,"text":173},{"id":258,"depth":494,"text":259},{"id":289,"depth":494,"text":290},{"id":359,"depth":494,"text":360},{"id":401,"depth":494,"text":402},{"id":449,"depth":494,"text":450},"架构设计","2026-06-24","md",{},true,"\u002Fblog\u002Fddd-strategic-design",{"title":5,"description":493},"DDD 实战","blog\u002Fddd-strategic-design",[514,515,516,504],"DDD","战略设计","限界上下文","zFSfvqTgCiGQ45Qweru33ibLRdmTf3O9hnYOtLeDIqM",1784193099134]