我有一些重用类似模型的微服务，即
可以在这些服务中的每一个中找到一个项目（汽车、自行车等），每次我添加新属性或新项目类型时，我最终都会在 3 个位置复制这些模型
我曾考虑将这些模型放在第四个库“ItemService”中，但由于这些模型在每个服务中具有不同的方法，因此 InventoryService 将能够修复项目等
但是，如果我的“ItemService”只包含这些模型的接口（只是状态而不是方法），然后其他服务实现，那么您可以在 ItemService 中找到 ICar，将其打包到 RepairService 中，然后实现它并添加修理汽车的方法。
我似乎在互联网上找不到任何关于让域实体实现接口的信息，所以我不是 100% 确定
干杯
【问题讨论】：
在之前的项目中，我们最终创建了一个单独的库，其中包含不同微服务使用的所有常见内容。我认为这与您在此处描述的情况相似。不同之处似乎是我们只对模型使用了普通的 bean（我知道，在你做 DDD 时不推荐）。
考虑到这种差异，使用装饰器怎么样？ 这意味着您在公共库中定义公共属性/行为，并在您使用的每个服务中使用所需的职责来装饰它们？
而且我不担心让域实体实现接口，如果你认为它有用，那就去做吧。我想不出有什么缺点。
【讨论】：
我对同一概念有一点write-up。
关键是各种有界上下文在同一个 thing 上做不同的事情，所以即使有一个特定实例的唯一标识符，比如 Car，你也会有该类在各种有界上下文中的不同实现。在许多（如果不是大多数）情况下，您可能会在每个特定的 BC 中拥有一个名称更相关的类。
然而，只有一个有界上下文会成为条目的记录系统。
【讨论】：
Radio 带入所有 BC 吗？可能存在与每个 BC 更相关的概念。 Car 和 Bike 可能是 MachineType 和 Gearbox 可能是 Rotable 或 Component 或 Maintenance BC 中的一些。这就是你将不得不以 UL 为指导的地方。