我正在努力增强为英国地区的消费者注册而开发的 Spring Boot 微服务。服务域模型和验证逻辑是根据英国的消费者注册详细信息进行编码的。微服务接受 UI 来提供消费者的姓名、地址等，并在向系统注册消费者之前对其进行一些验证。
我必须增强此服务才能在美国地区运行。现有的域模型不适合美国。在英国，消费者的地址格式与美国不同。此外，英国地区没有 SSN。英国和美国有不同的地址验证系统。
所以总的来说，我不能使用为美国地区开发的相同的微服务。我想问一下，考虑到域模型的差异以及与不同后端系统集成的要求（例如地址验证），我们如何开发跨不同地域的服务。
【问题讨论】：
标签： spring-boot design-patterns architecture microservices
这取决于领域模型的深度。如果域模型只是存在于微服务级别的东西，那么微服务级别的更改将修复它，但是，如果域模型一直深入到核心系统，那么微服务级别的更改将只是一个范围-最好的帮助。
问题不仅在于数据的处理方式，还在于数据在后端/核心系统中的存储方式。
在计划进行更改以适应美国时，可能值得询问的是以后添加其他地区的可能性有多大。这并不是说您想立即开始过度设计事物（YAGNI 等），但同时它可能会帮助您选择不会让自己陷入困境的选项。
回答您的实际问题：
...我们如何开发适用于不同地区的服务 考虑到领域模型和要求的差异 与不同的后端系统集成（地址验证 示例）。
这里有几个选项。这些有不同的变化，但希望它们能给你一个好的开始：
选项 A（左）：单个微服务中的逻辑
假设 UI（或调用微服务的任何东西）已确定需要哪个区域。在微服务中：
Logic Loader）可以加载正确的区域逻辑。SaveDwellingNumber(int streetNumber, int level, int apartmentNumber) 但是，正如您可以直接看到的那样，强类型方法签名是不可能的/不容易的。根据 UI 的工作方式，区域逻辑系统处理的功能之一可能是告诉 UI 要显示哪些区域特定的输入字段。
这个解决方案感觉有点脏，但它可以让您处理不同的区域，同时向只有一种理解地址的方式的后端系统提供一组统一的输出数据。
选项 B（右）：分层微服务
这与其他选项的工作原理相同，但实现方式不同。
consistency / mapper 的作用。此微服务也是对核心系统进行保护的好地方，例如在性能不佳时进行缓存。比较
选项 B 允许您更轻松地分离关注点，例如如果您的企业说“实际上我们可能会考虑在明年添加柬埔寨和拉脱维亚”，那么这种方法可能会给您提供更多选择，因为您只能合理地挤入单个微服务中。您还可以将相关微服务的实例部署到有意义的 *aaS 平台地理区域中。
如果您使用选项 A 弄清楚您的逻辑和功能框架，您可以稍后将其重新构建为选项 B。选项 A 是一个更小、更简单的实现，因此初始构建速度更快，但很难说它会持续多久。
选项 B 更加分隔，因此更容易让多个人/团队在其不同部分工作。
最后，只要这个答案是，它并没有真正解决不同数据中固有的挑战以及您需要什么逻辑，但它确实讨论了如何处理此类逻辑所在的微服务。
【讨论】：
归根结底，我假设您对用户详细信息进行了处理。因此，我认为最好的做法是开发适合所有区域需求的用户/地址域模型。
这很有可能。例如，请参阅How should international geographical addresses be stored in a relational database?。
保持简单。
【讨论】：