DDD многоразовые модели

Question

У меня есть несколько микросервисов, которые повторно используют похожие модели, например

• RepairService
• InventoryService
• AuctionService

An Item (Cars , Bikes, et c) можно найти в каждой из этих служб, и каждый раз, когда я добавляю новые свойства или новый тип элемента, я в конечном итоге дублирую эти модели в трех местах.

Я думал о том, чтобы разместить эти моделей в четвертой библиотеке «ItemService», но поскольку эти модели имеют разные методы в каждой службе, InventoryService сможет восстанавливать элементы и т. д. c

Но что, если бы мой «ItemService» содержал только интерфейсы для этих модели (просто состояние, а не методы), которые затем реализуют другие службы, чтобы вы могли найти ICar в ItemService, упаковать его в RepairService, который затем реализует его и добавляет методы для ремонта автомобиля.

Я могу ' Кажется, я нигде в inte rnet не нашел, что объекты домена реализуют интерфейсы, поэтому я не уверен на 100%

Chee RS

Answer 1

У меня есть небольшая рецензия на ту же концепцию.

Дело в том, что различные ограниченные контексты делают что-то по-разному с одним и тем же thing, поэтому даже при наличии уникального идентификатора для указанного c экземпляра, скажем, Car, у вас будут разные реализации этого класса в различных ограниченных контекстах. Во многих, если не в большинстве случаев, у вас, вероятно, будет класс с более подходящим именем в каждом конкретном B C.

Однако только один из ограниченных контекстов будет система записи для входа.

Answer 2

В предыдущем проекте мы закончили тем, что создали отдельную библиотеку со всем обычным материалом, используемым различными микросервисами. Я думаю, что это схожая ситуация с тем, что вы здесь описываете. Разница, кажется, в том, что мы использовали только простые бины для моделей (я знаю, не рекомендуется, если вы используете DDD).

Принимая во внимание эту разницу, как насчет использования Decorator? Это означает, что вы определяете общие свойства / поведение в общей библиотеке, а они украшают их необходимыми обязанностями в каждой используемой вами службе?

И я бы не стал беспокоиться о том, чтобы объекты домена реализуют интерфейсы, если вы думаете, что это полезно, просто сделайте это. Не могу вспомнить ни одного недостатка.