销售说的客户、开票时的购方和登录系统的账号，经常被塞进同一个 Customer 类。字段越加越多之后，任何修改都影响多个团队。服务边界的讨论可以先从这些词在不同流程中的实际含义开始。
先把名词放回业务动作
让销售、财务和研发分别说明“新增客户”“冻结客户”“修改客户名称”的含义。一个流程关心商机归属，另一个关心开票主体，还有一个只关心登录身份。名称相同不代表生命周期相同，名称不同也不一定意味着需要独立服务。
区分共享标识和共享内部结构
不同模块可以引用稳定的客户标识，但没有必要共享同一份内部实体对象。财务需要的可能是开票时的主体快照，而销售需要实时联系人。先约定哪些信息必须即时获取、哪些应该保留历史，再决定接口字段及同步方式。
用业务冲突验证边界
设想客户更名、主体合并、账号注销等情形，检查哪些状态应变化、哪些历史记录必须保持。把冲突写进示例与契约测试，比仅画一个 Customer Service 方框更能说明边界。讨论仍可发生在模块化单体内，不必立刻部署多个进程。
交付物是一份语义与责任表
列明术语、业务含义、数据所有者、外部标识和变更通知规则。验收时让不同团队独立解释一项变更，确认不会产生相反实现。后续确实需要独立发布时，再把已经清晰的模块移出单体。
常见问题：所有重复字段都应该消除吗？
不一定。业务快照与当前资料承担不同责任。先说明每份数据为什么存在、何时更新和由谁负责，再判断它是合理副本还是失控重复。
技术参考：微软：领域分析与微服务边界。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果你的团队正遇到类似问题，可以从一条关键业务路径开始，整理现状、证据与约束，通过系统架构诊断明确优先级、候选方案和验证范围。