Как создать кросс-сервисную модель доменной модели? - PullRequest
1 голос
/ 02 октября 2019

У меня есть два микро-сервиса в архитектуре микро-сервисов Spring Boot. Допустим ...

  • Служба HotSpot
  • Служба вложений

Обе службы содержат модель домена, разумеется, в конце концов, в отдельных JAR-файлах.

Модель домена HotSpot (служба HotSpot)

@Entity
public class HotSpot {

    @Id
    private Long id;
}

Модель домена подключения (служба вложений)

@Entity
public class Attachment {

    @Id
    private Long id;
}

ЕслиВы создаете новую горячую точку, должна быть возможность добавить дополнительное вложение, например, описывающее изображение. Таким образом, должна существовать какая-то связь / отображение между сущностью горячей точки и ее привязанностью. В монолитном приложении это может быть реализовано с помощью аннотации JPA @OneToOne или чего-то подобного.

Как этого добиться в архитектуре микросервиса? Оба класса находятся в отдельных JAR / проектах! Я думал о хранении только идентификатора как Long независимо от JPA. Какие-нибудь "лучшие" / другие идеи?

Ответы [ 2 ]

2 голосов
/ 02 октября 2019

Сначала я хотел бы спросить, как вы делите свои микро услуги? Не имеет смысла разделять ресурсы, которые зависят друг от друга. В вашем примере я не уверен, что вложение может существовать без HotSpot. Если это невозможно, окончательно не имеет смысла иметь эти две сущности в двух отдельных микро-сервисах.

Предполагается, что ваши ресурсы должны быть разделены на две микро-службы, для каждого ресурса вам потребуется URI. Если ресурс A связан с ресурсом B, вы можете просто сохранить URI B в A, и если ваши mircroservices должны быть RESTful, предоставляет ссылку в A на B с правильным соотношением. Никакой автоматической системы, такой как отношение JPA OneToOne, не существует.

0 голосов
/ 02 октября 2019

У нас есть полуобобщенная служба (например, служба прикрепления в вашем примере) для тегирования. Вы можете использовать структуру, аналогичную той, которую мы используем, что-то вроде этого:

// Contains types of "things" that can accept attachments
// Probably unnecessary if you aren't multi-tenant
public class EntityType
{
   public int Id;
   public Guid TenantId;
   public string Name;
}

// Contains a list of Entities available to Attach to
public class Entity
{
   public int Id;
   public int EntityTypeId;
   public string EntityId; // The unique Identifier for this Instance of Entity
}

// Contains actual attachment values (URI's) assigned to an Entity instance
public class EntityAttachment
{
   public int Id;
   public int EntityId;
   public string Attachment;
}

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

Мы создаем наборы данных EntityType и Entity на лету - если кто-то хочет добавить тег к типуили ID у нас нет, мы добавляем его молча.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...