限界上下文划清楚，那两个团队才不踩到彼此的线
限界上下文是领域驱动设计里划地盘的概念，地盘划清楚了，两个团队改同一块的概率就小。小了冲突少，少了扯皮，扯皮省下的时间够做不少正事。一、边界画清楚
冲突少了不用天天开会对齐，对齐会开多了，真正写代码的时间反而被挤没。边界模糊的地方单列出来，单列了专门有人拍板不悬在空中。防腐层挡住外部模型，挡住了内部才不会被别人的字段带歪。
边界不是画在纸上就完事，要落到代码目录和部署单元上。只画在纸上的边界，三个月后新人一来就跨着写，跨着写一次，边界就开始模糊，模糊到没人记得原样。上下文边界画清楚，两个团队改同一块的概率就小，小了冲突少。聚合根之间靠事件通消息，消息比直接调用更松，松了才好扩。防腐层别太厚，厚到把业务逻辑包进去，内部反而被架空。
二、只通过明面接口说话
绕过去的调用，监控看不到，看不到就无法统一治理，治理缺一角，一角慢慢烂成一片。上下文不要按部门凑，凑出来的边界往往和真实业务对不上。外部接口变了先改防腐层，改这一层内部业务逻辑纹丝不动。
明面接口要契约化，契约化了双方按约来，按约来才不会一方改了另一方蒙在鼓里。蒙在鼓里的那方上线就挂，挂了查半天才发现是对方偷偷改了字段。上下文之间只通过明面接口说话，私底下绕过去早晚出乱子。聚合的不变规则写进根，写进去别处改不了，改不了才稳。
三、共享模型要谨慎
强塞之后，乙方用的客户和甲方用的客户不是一回事，不是一回事却在同一个类里，类里逻辑拧成麻花。重构时先守住边界，守住了内部怎么改都不波及外部调用方。防腐层做转换别做业务，做业务的那个职责就乱了，乱了难查。
各自保留自己的领域模型，需要交换时就做映射。映射写在上下文边界处，写在边界处才好维护，维护的人一看就知道这处是转换，转换错了也只影响这一处。共享模型要谨慎，一谨慎才不致把一个团队的词强塞给另一个。新建聚合先画关系，画清楚了才知道谁引用谁，引用错了难收。
四、边界变更走评审
广到什么程度，往往是动完才发现牵出隔壁团队的需求，需求一动他们全员加班。聚合根定好了，一次操作该不该跨实体就有了裁判，裁判明了才不乱。多个外部系统各接各的防腐层，混一起哪天一个改了全乱套。
评审还要拉上受影响方，拉上了对方提前知道，提前知道就能在自己的排期里留余地。留了余地，变更来了不慌，慌的是完全不知情被撞的那一种。边界变更要走评审，评审过了再动，动错了影响面比想象广。聚合加载要控制深度，深度不限会把一大片无关数据一起拽出来。
五、术语要统一
读不懂的代码，改的时候靠猜，猜错了埋个雷，雷过阵子爆，爆出来还是新人背锅。聚合内得保住一致，一致性守不住数据就出现自相矛盾的状态。防腐层要有测试，测试护着它，外部一变测试先红，红了早知。
统一术语要落到字典里，落到字典里才不会各叫各的。各叫各的，一个概念三个名，三个名对应同一张表，表上加字段的人根本不知道重复了，重复了查询就乱。上下文内的术语要统一，统一了新人进来才读得懂彼此的代码。聚合根标识要稳定，稳定了别处引用才不会指到一半断了。
六、跨上下文调用要记账
失衡到某个上下文被十几个服务依赖，那个上下文一升级，十几个团队排队等，等的过程中业务停滞。聚合别设计太大，太大锁的范围广，广了并发上来互相卡。转换逻辑集中放，放散了同样规则写两遍，两遍对不上就坏事。
记账还要标清调用性质，是强依赖还是弱引用，标清了架构师才看得出风险点。看得出风险点，才敢对那个高依赖的上下文重点保护，保护到位少出事。跨上下文调用要记账，记账后能看清依赖的重心在哪，重心失衡要命。聚合设计要评审，评审能拦住把本该分开的硬塞进一个根。
限界上下文是给不清楚的微服务世界划界，划界不是为了好看，是为了让团队各管各的还能互不踩。边界、接口、模型、评审、术语、记账，六件事做实，上下文才真是护城河。 这样用心的帖子不多见，必须顶上去让更多人看到优质内容。
页:
[1]