限界上下文

更新: 3/15/2025 字数: 0 字时长: 0 分钟

不知道小伙伴们有没有设计过用户登录系统和用户信息系统

这两个系统就算是初学者也应该见过吧~~（大学作业）~~，这里面就会产生一个最简单的问题——用户信息系统会频繁的修改用户的基本信息，而用户登录系统可能需要使用用户信息去登陆。

然后如果这两个系统是分开设计，那么构建的时候两者就会产生矛盾——为什么我这里有用户了，你哪里还要设计用户。

这其实就是一个经典的限界上下文的问题，因为二者所属的领域不同，因此Aggregate的内容也不用，用户信息系统可能更关心用户的角色，昵称，性别，邮箱，而用户登录系统更关心用户的密码，邮箱。

发现了吗，虽然有重合字段，但二者本身关注的内容并不一样，甚至进一步的说如果用户信息系统不需要什么逻辑校验的化，甚至就是一个单纯的读事件，设计时甚至可以不用DDD（没有业务，直接退化为纯CRUD）

侵入

当存在了多个团队/多个模块之间的合作，那么侵入就出现了

当我们使用别人的模块的代码时，如果对方没有直接提供接口，那么我们就只能江对面的代码引入到我们的代码里面。

初期看着可能问题不大，但是后续过程，如果被依赖的团队的模块出现了大修改，那么我们就要跟着一同修改，这样问题就会很大

防腐层这个概念不知道大家有没有听说过，防腐层的出现其实就是为了在一定程度上解决限界上下文的问题

我们的一个项目难免会使用外部框架，或者在企业中，我们的模块可能需要依赖别的团队的模块，这个时候我们该如何解决对方对我们的侵入呢？

一个简单的做法就是单独设计一层，将具有侵入性的代码放在这一层，然后再将其转换为我们模块内部需要的形式，这样就把侵入控制在了这一个层里面，这就是我们的防腐层