1. 项目概述从“一团乱麻”到“泾渭分明”的领域划分实战在软件架构的江湖里DDD领域驱动设计早已不是新鲜词汇但真正能把它用明白、用出效果的团队却不多。我见过太多项目一上来就大谈特谈“聚合根”、“实体”、“值对象”画了一堆精美的领域模型图结果代码一落地各个模块还是纠缠不清边界模糊最后又回到了“大泥球”的老路。问题的症结往往不在于战术设计那些实体、值对象没学好而在于战略设计的第一步——子域划分就没走对。特别是对核心域、支撑域、通用域这三个概念的理解和应用直接决定了整个系统的架构生命力和演进方向。简单来说你可以把开发一个复杂系统想象成经营一家公司。核心域就是你的核心业务部门是公司的命脉和独特竞争力所在比如特斯拉的电池管理技术、字节跳动的推荐算法。支撑域则是那些辅助核心业务运转的职能部门比如人力资源、财务、法务它们不直接创造核心价值但缺了它们公司就无法正常运营。通用域则是市场上就能买到的标准化服务或产品比如办公软件、云服务器、差旅预订平台自己从头造轮子既不经济也不专业。这次我们不空谈理论而是结合我过去在多个中大型项目从电商平台到物联网中台中踩过的坑、总结的经验来一次彻底的“领域划分”实战拆解。我会告诉你为什么仅仅知道定义不够如何在实际项目中识别它们更重要的是不同的域应该匹配怎样不同的资源投入、团队组织和技术策略。这不仅是架构师的功课更是产品、技术负责人乃至每一位开发者都需要建立的共识。2. 核心域、支撑域、通用域的本质区别与识别心法2.1 定义再辨析超越教科书的理解很多资料会给这三个概念下定义但定义是静态的业务是动态的。我更喜欢从投资回报率ROI和业务差异性两个维度来动态理解它们。核心域这是公司的“护城河”。它的特点是高业务价值、高复杂性、高差异性。投资在这里是为了建立竞争对手难以模仿的竞争优势。识别核心域的一个灵魂拷问是“如果这个功能/模块做得和竞争对手一模一样甚至还不如他们我们的产品还有生存空间吗” 例如对于一个外卖平台智能订单调度系统如何在最短时间、最优路径下分配订单给骑手就是核心域。它的算法直接决定了配送效率和用户体验是平台的核心竞争力。支撑域这是业务的“润滑剂”。它的特点是专业性高、但非独有。它支撑核心业务流程的运转但本身不构成直接的市场差异化优势。例如上述外卖平台的商户结算系统、骑手佣金计算系统。这些系统业务逻辑复杂涉及各种优惠分摊、阶梯佣金规则必须自己精心打造以确保业务合规和准确但你说它能像调度算法那样形成技术壁垒吗很难。它更偏向于复杂的内部业务规则实现。通用域这是行业的“水电煤”。它的特点是低差异性、高标准化。几乎每个系统都需要但完全没有必要自己实现。例如用户身份认证AuthN、权限管理AuthZ、消息推送、文件存储等。在这些领域使用成熟的开源方案如 Keycloak、Casbin或商业云服务如 AWS Cognito, 阿里云OSS是性价比最高的选择。注意一个域的归属不是一成不变的。随着业务发展通用域可能演变为支撑域支撑域也可能沉淀为核心域。例如早期电商的“搜索”可能用ES简单实现通用域但随着业务复杂化需要融合用户画像、实时销量、个性化策略它就变成了搜索推荐中台成为核心域。2.2 实战识别四步法从会议争吵到达成共识理论清晰后如何在项目启动或重构初期带领团队包括产品、业务、研发一起识别出这些域呢我总结了一个四步工作法亲测有效。事件风暴梳理业务流程召集所有关键角色用便签纸梳理出业务全链路的所有领域事件如“订单已创建”、“支付已成功”、“货物已出库”。这个过程能让大家对业务全景达成一致避免后期“盲人摸象”。命令与聚合根设计针对每个事件找出触发它的命令谁、在什么条件下、做了什么操作并初步识别出承载这些命令和数据的聚合根如“订单聚合”、“用户聚合”。这时模块的雏形开始浮现。绘制上下文映射图这是关键一步。将上一步识别出的聚合根簇根据功能内聚性初步归类到不同的限界上下文中。然后开始用我们三个域的标尺去衡量每一个上下文。判断标准1价值这个上下文提供的功能是直接让我们在市场上脱颖而出的吗核心域候选判断标准2复杂度这个上下文的业务规则是否极其复杂、频繁变化且市面上没有成熟方案支撑域候选判断标准3通用性这个上下文的功能是否在几乎所有同类系统中都存在且有无数成熟、稳定的开源或商业解决方案通用域候选达成战略共识将绘制好的、带有域分类的上下文映射图公开讨论。这时常会有争论比如“风控系统到底算核心还是支撑” 解决争论的最好办法就是回溯到公司当前的战略重点。如果公司现阶段的目标是极致交易体验那么“交易风控”可能就是核心域如果目标是规模扩张那么它可能先作为支撑域保证业务跑通即可。3. 不同域的架构与团队治理策略识别出来只是第一步更重要的是对不同域采取不同的“治理”策略。用管理核心业务部门的方法去管理后勤部门或者反之都会造成巨大的浪费和冲突。3.1 核心域重兵投入精耕细作核心域是必须集中优势兵力打歼灭战的地方。架构策略技术选型自由度高允许甚至鼓励团队为了业务目标尝试最新的、最适合的技术栈。例如为了处理实时调度中的复杂优化问题可以引入专门的运筹学求解器或图计算引擎。模型精益演进领域模型会随着业务理解深入而频繁重构。架构上要为此留足空间采用防腐层Anticorruption Layer隔离外部变化保持核心模型的纯净与演进能力。独立部署与高可用核心域系统必须具备独立部署、独立扩容的能力。通常采用微服务架构并配备最高的监控、告警和故障恢复等级。团队策略组建跨功能“特战小队”团队应包含产品、业务分析、开发、测试等角色且人员相对稳定、资深。他们需要对业务有深刻的理解而不仅仅是技术实现者。授权与共担给予团队高度的自主权对业务结果如调度效率提升X%、推荐点击率提升Y%共同负责。采用产品团队模式而非项目模式。实操心得在核心域切忌为了“技术统一性”而强行统一技术栈。我们曾在一个AI项目中强迫核心的机器学习模型服务也使用公司主流的Java技术栈结果在模型迭代效率和性能上吃了大亏。后来改为允许使用Python并定义清晰的RESTful API边界问题迎刃而解。3.2 支撑域稳字当头效率优先支撑域的目标是“稳定、准确、高效”地支持核心业务而不是追求技术炫技。架构策略技术栈适度统一倾向于使用团队熟悉、稳定、生态完善的主流技术栈以降低维护成本和人员协作门槛。例如公司内部Java是主流那么支撑域就优先选用Spring Cloud生态。清晰的服务契约对外提供稳定、版本化的API。内部逻辑可以复杂但接口要简单明了。变更需要严格的通知和兼容性保证。可靠性设计虽然重要性略低于核心域但稳定性要求依然很高。需考虑幂等、重试、补偿事务等设计避免因支撑域故障导致核心业务流程中断。团队策略专业化团队可以按照职能领域组织团队如“结算团队”、“风控团队”。团队成员需要是该业务领域的专家。服务意识团队要有强烈的服务意识将核心域团队视为自己的“客户”主动管理需求、沟通变更、保障SLA。常见问题支撑域最容易沦为“垃圾堆”所有不明确归属的功能都往里塞。必须坚守其边界。我们曾有个“运营平台”支撑域后来被塞进了活动配置、消息推送、数据报表等十几种功能变得无比臃肿最终不得不进行痛苦的拆分。3.3 通用域拿来主义控制成本对于通用域核心思想是“不要重复造轮子”。架构策略首选成熟方案全面评估市场上的开源解决方案如Apollo配置中心、RocketMQ消息队列或云厂商的托管服务如AWS RDS, Auth0。将自研作为最后选项。标准化接入即使采用外部方案也要在公司内部制定标准的接入、监控、运维规范。例如所有服务接入消息队列必须使用公司封装的客户端统一配置监控和日志。建立技术雷达有专门团队如架构组或平台组负责跟踪、评估、引入和推广优秀的通用技术方案。团队策略平台/运维团队主导由负责基础技术设施的团队负责选型、搭建、维护和推广。他们需要提供清晰的文档、工具和最佳实践。赋能而非接管这些团队的目标是让业务团队能更便捷、更安全地使用这些通用能力而不是接管业务团队的开发工作。避坑技巧警惕“魔改”开源组件。除非有极其强烈的、无法规避的业务需求否则尽量使用开源组件的标准版本和接口。我们曾为了一个非关键的特性深度定制了一个开源配置中心结果后续版本升级变得异常困难背上了沉重的技术债。4. 上下文映射连接不同域的协作模式限界上下文划分好后它们之间如何协作这就是上下文映射Context Mapping要解决的问题。针对不同域之间的交互应采用不同的映射模式。核心域 - 核心域尽量避免直接同步调用采用发布/订阅事件的异步协作模式。例如“订单核心域”在订单完成后发布“OrderCompleted”事件“库存核心域”和“积分核心域”各自订阅并处理。这能极大解耦提高系统整体韧性。核心域 - 支撑域通常采用客户-供应商Customer-Supplier模式。核心域作为客户支撑域作为供应商双方共同制定并遵守明确的API契约如Protobuf/OpenAPI规范。支撑域团队有责任满足核心域团队的需求。任何域 - 通用域采用遵奉者Conformist模式。业务域无条件遵从通用域无论是自研平台还是外部服务定义好的模型和协议。例如所有服务接入认证中心都必须使用其提供的SDK和Token格式。处理遗留系统或外部不可控系统使用防腐层ACL。在核心域边界建立一个翻译层将外部“肮脏”的模型转换成内部干净的领域模型避免污染核心域。例如对接一个第三方物流系统其API返回的数据结构非常糟糕我们就在物流聚合根外建立一个ACL来进行转换。5. 实战案例一个中型电商平台的领域划分演进让我们看一个简化的案例。一个初创电商平台最初可能只有几个简单的上下文商品上下文管理商品信息。初期可视为支撑域因为简单当需要复杂的类目管理、属性体系、搜索优化时可能变为核心域订单上下文处理下单、支付流程。核心域直接关乎交易体验和成功率用户上下文管理用户注册、登录、基本信息。初期作为通用域直接使用第三方登录后期为统一会员体系可能转为支撑域甚至核心域——如果用户画像和精准营销成为重点库存上下文管理商品库存。支撑域逻辑复杂但非独有营销上下文优惠券、秒杀活动。初期作为支撑域当促销玩法成为主要拉新手段时可升级为核心域随着业务发展平台发现“个性化推荐”是提升复购的关键于是拆分出 6.推荐上下文基于用户行为进行商品推荐。核心域投入算法工程师和数据分析师重点建设同时为了提升效率将通用能力剥离 7.消息通知上下文集成短信、邮件、App推送服务。通用域选用阿里云短信服务第三方推送SDK 8.文件服务上下文处理图片、视频上传。通用域直接使用对象存储OSS通过这样的划分和演进每个上下文的定位、技术策略和团队配置都清晰了。订单、推荐作为核心域由精锐小队使用更灵活的技术栈深度打磨库存、营销作为支撑域由业务专家团队保证稳定高效消息、文件作为通用域由平台团队统一管理云服务最大化利用社会生产力。6. 常见误区与避坑指南误区一把技术组件当成分域的维度。错误“我们的核心域是MySQL和Redis。” 正确分域的依据是业务能力而不是数据库、缓存这些技术组件。技术是为业务领域服务的。误区二核心域过大什么都往里装。错误认为所有重要的都是核心域。结果核心域团队负担过重资源稀释真正需要创新的地方反而投入不足。必须残酷地 prioritise真正的核心域可能只有1-2个。误区三支撑域和通用域混淆。错误将应该采购的通用能力如短信发送进行自研耗费大量人力做出一个不稳定、功能少的轮子。或者将需要深度定制、蕴含复杂业务规则的支撑域如内部结算系统草率地使用外部SaaS导致业务无法灵活发展。误区四划分后一成不变。错误在项目初期划分一次后就束之高阁。领域划分需要定期如每季度或每半年结合业务战略进行回顾和调整。昨天的支撑域可能是明天的核心域。误区五忽略了团队结构。“康威定律”指出系统架构会反映组织的沟通结构。如果核心域对应的是一个臃肿、沟通低效的大团队那么再好的领域设计也无法落地。理想情况下一个限界上下文最好能由一个5-9人的、跨职能的、沟通顺畅的小团队独立负责。识别和管理好核心域、支撑域、通用域是DDD战略设计中最具价值的一环。它迫使我们从业务价值、投资回报和公司战略的角度去思考技术决策而不仅仅是技术实现本身。这不仅仅是一种架构方法更是一种资源分配的艺术和产品思维的体现。当你下次面对一个复杂系统时不妨先问一句“它的核心域到底是什么” 这个问题的答案将指引你做出后续一系列正确的技术和管理决策。 DDD战略设计实战：核心域、支撑域、通用域的划分心法与架构治理
1. 项目概述从“一团乱麻”到“泾渭分明”的领域划分实战在软件架构的江湖里DDD领域驱动设计早已不是新鲜词汇但真正能把它用明白、用出效果的团队却不多。我见过太多项目一上来就大谈特谈“聚合根”、“实体”、“值对象”画了一堆精美的领域模型图结果代码一落地各个模块还是纠缠不清边界模糊最后又回到了“大泥球”的老路。问题的症结往往不在于战术设计那些实体、值对象没学好而在于战略设计的第一步——子域划分就没走对。特别是对核心域、支撑域、通用域这三个概念的理解和应用直接决定了整个系统的架构生命力和演进方向。简单来说你可以把开发一个复杂系统想象成经营一家公司。核心域就是你的核心业务部门是公司的命脉和独特竞争力所在比如特斯拉的电池管理技术、字节跳动的推荐算法。支撑域则是那些辅助核心业务运转的职能部门比如人力资源、财务、法务它们不直接创造核心价值但缺了它们公司就无法正常运营。通用域则是市场上就能买到的标准化服务或产品比如办公软件、云服务器、差旅预订平台自己从头造轮子既不经济也不专业。这次我们不空谈理论而是结合我过去在多个中大型项目从电商平台到物联网中台中踩过的坑、总结的经验来一次彻底的“领域划分”实战拆解。我会告诉你为什么仅仅知道定义不够如何在实际项目中识别它们更重要的是不同的域应该匹配怎样不同的资源投入、团队组织和技术策略。这不仅是架构师的功课更是产品、技术负责人乃至每一位开发者都需要建立的共识。2. 核心域、支撑域、通用域的本质区别与识别心法2.1 定义再辨析超越教科书的理解很多资料会给这三个概念下定义但定义是静态的业务是动态的。我更喜欢从投资回报率ROI和业务差异性两个维度来动态理解它们。核心域这是公司的“护城河”。它的特点是高业务价值、高复杂性、高差异性。投资在这里是为了建立竞争对手难以模仿的竞争优势。识别核心域的一个灵魂拷问是“如果这个功能/模块做得和竞争对手一模一样甚至还不如他们我们的产品还有生存空间吗” 例如对于一个外卖平台智能订单调度系统如何在最短时间、最优路径下分配订单给骑手就是核心域。它的算法直接决定了配送效率和用户体验是平台的核心竞争力。支撑域这是业务的“润滑剂”。它的特点是专业性高、但非独有。它支撑核心业务流程的运转但本身不构成直接的市场差异化优势。例如上述外卖平台的商户结算系统、骑手佣金计算系统。这些系统业务逻辑复杂涉及各种优惠分摊、阶梯佣金规则必须自己精心打造以确保业务合规和准确但你说它能像调度算法那样形成技术壁垒吗很难。它更偏向于复杂的内部业务规则实现。通用域这是行业的“水电煤”。它的特点是低差异性、高标准化。几乎每个系统都需要但完全没有必要自己实现。例如用户身份认证AuthN、权限管理AuthZ、消息推送、文件存储等。在这些领域使用成熟的开源方案如 Keycloak、Casbin或商业云服务如 AWS Cognito, 阿里云OSS是性价比最高的选择。注意一个域的归属不是一成不变的。随着业务发展通用域可能演变为支撑域支撑域也可能沉淀为核心域。例如早期电商的“搜索”可能用ES简单实现通用域但随着业务复杂化需要融合用户画像、实时销量、个性化策略它就变成了搜索推荐中台成为核心域。2.2 实战识别四步法从会议争吵到达成共识理论清晰后如何在项目启动或重构初期带领团队包括产品、业务、研发一起识别出这些域呢我总结了一个四步工作法亲测有效。事件风暴梳理业务流程召集所有关键角色用便签纸梳理出业务全链路的所有领域事件如“订单已创建”、“支付已成功”、“货物已出库”。这个过程能让大家对业务全景达成一致避免后期“盲人摸象”。命令与聚合根设计针对每个事件找出触发它的命令谁、在什么条件下、做了什么操作并初步识别出承载这些命令和数据的聚合根如“订单聚合”、“用户聚合”。这时模块的雏形开始浮现。绘制上下文映射图这是关键一步。将上一步识别出的聚合根簇根据功能内聚性初步归类到不同的限界上下文中。然后开始用我们三个域的标尺去衡量每一个上下文。判断标准1价值这个上下文提供的功能是直接让我们在市场上脱颖而出的吗核心域候选判断标准2复杂度这个上下文的业务规则是否极其复杂、频繁变化且市面上没有成熟方案支撑域候选判断标准3通用性这个上下文的功能是否在几乎所有同类系统中都存在且有无数成熟、稳定的开源或商业解决方案通用域候选达成战略共识将绘制好的、带有域分类的上下文映射图公开讨论。这时常会有争论比如“风控系统到底算核心还是支撑” 解决争论的最好办法就是回溯到公司当前的战略重点。如果公司现阶段的目标是极致交易体验那么“交易风控”可能就是核心域如果目标是规模扩张那么它可能先作为支撑域保证业务跑通即可。3. 不同域的架构与团队治理策略识别出来只是第一步更重要的是对不同域采取不同的“治理”策略。用管理核心业务部门的方法去管理后勤部门或者反之都会造成巨大的浪费和冲突。3.1 核心域重兵投入精耕细作核心域是必须集中优势兵力打歼灭战的地方。架构策略技术选型自由度高允许甚至鼓励团队为了业务目标尝试最新的、最适合的技术栈。例如为了处理实时调度中的复杂优化问题可以引入专门的运筹学求解器或图计算引擎。模型精益演进领域模型会随着业务理解深入而频繁重构。架构上要为此留足空间采用防腐层Anticorruption Layer隔离外部变化保持核心模型的纯净与演进能力。独立部署与高可用核心域系统必须具备独立部署、独立扩容的能力。通常采用微服务架构并配备最高的监控、告警和故障恢复等级。团队策略组建跨功能“特战小队”团队应包含产品、业务分析、开发、测试等角色且人员相对稳定、资深。他们需要对业务有深刻的理解而不仅仅是技术实现者。授权与共担给予团队高度的自主权对业务结果如调度效率提升X%、推荐点击率提升Y%共同负责。采用产品团队模式而非项目模式。实操心得在核心域切忌为了“技术统一性”而强行统一技术栈。我们曾在一个AI项目中强迫核心的机器学习模型服务也使用公司主流的Java技术栈结果在模型迭代效率和性能上吃了大亏。后来改为允许使用Python并定义清晰的RESTful API边界问题迎刃而解。3.2 支撑域稳字当头效率优先支撑域的目标是“稳定、准确、高效”地支持核心业务而不是追求技术炫技。架构策略技术栈适度统一倾向于使用团队熟悉、稳定、生态完善的主流技术栈以降低维护成本和人员协作门槛。例如公司内部Java是主流那么支撑域就优先选用Spring Cloud生态。清晰的服务契约对外提供稳定、版本化的API。内部逻辑可以复杂但接口要简单明了。变更需要严格的通知和兼容性保证。可靠性设计虽然重要性略低于核心域但稳定性要求依然很高。需考虑幂等、重试、补偿事务等设计避免因支撑域故障导致核心业务流程中断。团队策略专业化团队可以按照职能领域组织团队如“结算团队”、“风控团队”。团队成员需要是该业务领域的专家。服务意识团队要有强烈的服务意识将核心域团队视为自己的“客户”主动管理需求、沟通变更、保障SLA。常见问题支撑域最容易沦为“垃圾堆”所有不明确归属的功能都往里塞。必须坚守其边界。我们曾有个“运营平台”支撑域后来被塞进了活动配置、消息推送、数据报表等十几种功能变得无比臃肿最终不得不进行痛苦的拆分。3.3 通用域拿来主义控制成本对于通用域核心思想是“不要重复造轮子”。架构策略首选成熟方案全面评估市场上的开源解决方案如Apollo配置中心、RocketMQ消息队列或云厂商的托管服务如AWS RDS, Auth0。将自研作为最后选项。标准化接入即使采用外部方案也要在公司内部制定标准的接入、监控、运维规范。例如所有服务接入消息队列必须使用公司封装的客户端统一配置监控和日志。建立技术雷达有专门团队如架构组或平台组负责跟踪、评估、引入和推广优秀的通用技术方案。团队策略平台/运维团队主导由负责基础技术设施的团队负责选型、搭建、维护和推广。他们需要提供清晰的文档、工具和最佳实践。赋能而非接管这些团队的目标是让业务团队能更便捷、更安全地使用这些通用能力而不是接管业务团队的开发工作。避坑技巧警惕“魔改”开源组件。除非有极其强烈的、无法规避的业务需求否则尽量使用开源组件的标准版本和接口。我们曾为了一个非关键的特性深度定制了一个开源配置中心结果后续版本升级变得异常困难背上了沉重的技术债。4. 上下文映射连接不同域的协作模式限界上下文划分好后它们之间如何协作这就是上下文映射Context Mapping要解决的问题。针对不同域之间的交互应采用不同的映射模式。核心域 - 核心域尽量避免直接同步调用采用发布/订阅事件的异步协作模式。例如“订单核心域”在订单完成后发布“OrderCompleted”事件“库存核心域”和“积分核心域”各自订阅并处理。这能极大解耦提高系统整体韧性。核心域 - 支撑域通常采用客户-供应商Customer-Supplier模式。核心域作为客户支撑域作为供应商双方共同制定并遵守明确的API契约如Protobuf/OpenAPI规范。支撑域团队有责任满足核心域团队的需求。任何域 - 通用域采用遵奉者Conformist模式。业务域无条件遵从通用域无论是自研平台还是外部服务定义好的模型和协议。例如所有服务接入认证中心都必须使用其提供的SDK和Token格式。处理遗留系统或外部不可控系统使用防腐层ACL。在核心域边界建立一个翻译层将外部“肮脏”的模型转换成内部干净的领域模型避免污染核心域。例如对接一个第三方物流系统其API返回的数据结构非常糟糕我们就在物流聚合根外建立一个ACL来进行转换。5. 实战案例一个中型电商平台的领域划分演进让我们看一个简化的案例。一个初创电商平台最初可能只有几个简单的上下文商品上下文管理商品信息。初期可视为支撑域因为简单当需要复杂的类目管理、属性体系、搜索优化时可能变为核心域订单上下文处理下单、支付流程。核心域直接关乎交易体验和成功率用户上下文管理用户注册、登录、基本信息。初期作为通用域直接使用第三方登录后期为统一会员体系可能转为支撑域甚至核心域——如果用户画像和精准营销成为重点库存上下文管理商品库存。支撑域逻辑复杂但非独有营销上下文优惠券、秒杀活动。初期作为支撑域当促销玩法成为主要拉新手段时可升级为核心域随着业务发展平台发现“个性化推荐”是提升复购的关键于是拆分出 6.推荐上下文基于用户行为进行商品推荐。核心域投入算法工程师和数据分析师重点建设同时为了提升效率将通用能力剥离 7.消息通知上下文集成短信、邮件、App推送服务。通用域选用阿里云短信服务第三方推送SDK 8.文件服务上下文处理图片、视频上传。通用域直接使用对象存储OSS通过这样的划分和演进每个上下文的定位、技术策略和团队配置都清晰了。订单、推荐作为核心域由精锐小队使用更灵活的技术栈深度打磨库存、营销作为支撑域由业务专家团队保证稳定高效消息、文件作为通用域由平台团队统一管理云服务最大化利用社会生产力。6. 常见误区与避坑指南误区一把技术组件当成分域的维度。错误“我们的核心域是MySQL和Redis。” 正确分域的依据是业务能力而不是数据库、缓存这些技术组件。技术是为业务领域服务的。误区二核心域过大什么都往里装。错误认为所有重要的都是核心域。结果核心域团队负担过重资源稀释真正需要创新的地方反而投入不足。必须残酷地 prioritise真正的核心域可能只有1-2个。误区三支撑域和通用域混淆。错误将应该采购的通用能力如短信发送进行自研耗费大量人力做出一个不稳定、功能少的轮子。或者将需要深度定制、蕴含复杂业务规则的支撑域如内部结算系统草率地使用外部SaaS导致业务无法灵活发展。误区四划分后一成不变。错误在项目初期划分一次后就束之高阁。领域划分需要定期如每季度或每半年结合业务战略进行回顾和调整。昨天的支撑域可能是明天的核心域。误区五忽略了团队结构。“康威定律”指出系统架构会反映组织的沟通结构。如果核心域对应的是一个臃肿、沟通低效的大团队那么再好的领域设计也无法落地。理想情况下一个限界上下文最好能由一个5-9人的、跨职能的、沟通顺畅的小团队独立负责。识别和管理好核心域、支撑域、通用域是DDD战略设计中最具价值的一环。它迫使我们从业务价值、投资回报和公司战略的角度去思考技术决策而不仅仅是技术实现本身。这不仅仅是一种架构方法更是一种资源分配的艺术和产品思维的体现。当你下次面对一个复杂系统时不妨先问一句“它的核心域到底是什么” 这个问题的答案将指引你做出后续一系列正确的技术和管理决策。