Как разделить определения классов между проектами в asp. net Ядро, упакованное в docker

Question

Итак, у меня есть архитектура с несколькими различными «back-end» asp. net основными веб-интерфейсами. Я использую Masstransit и rabbitmq для облегчения взаимодействия между контейнерами. С MassTransit сервисам нужен своего рода контракт между ними (просто простые классы), который, если система развернута локально или на сервере, подойдет, но с контейнерами docker это оказалось проблемой.

Я много пробовал гуглить, но, похоже, очень мало asp. net ядра и особенно мастранзита в сочетании с docker документацией.

Так что вопрос:

Как мне разделить контейнеры, написанные с помощью ядра asp. net, совместно использовать контракты обмена сообщениями (т.е. классы моделей)?

Я думал о создании пакета слепков. Это бы сработало, но кажется, что довольно не элегантное решение + контракты были бы опубликованы c (не имеет большого значения, но все же, вероятно, не очень).

наконец, я организую услуги с docker -compose - если это имеет отношение к вашему ответу.

Answer 1

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

1. Создайте отдельный репозиторий, опубликуйте sh как NuGet пакет. Вы можете сделать это в частном порядке, используя репозиторий пакетов GitHub, чтобы ваши контракты не размещались на общедоступном сайте NuGet c. Это дает вам единственное место, но становится единственной точкой разногласия для контрактов на сообщения. Хорошо: это просто, и контракты не должны меняться , а новые версии должны быть разработаны с обратной совместимостью, поскольку не все службы будут обновлены до последней версии.

2. Скопируйте классы (хотя я лично предпочитаю интерфейсы, но это другая история) в ваш проект - в том числе пространство имен. Некоторые люди из ОКР волнуются по этому поводу, но, честно говоря, мы делаем что-то другое с JSON и HTTP? Если контракты управляются хорошо, и владельцы демонстрируют контроль в обеспечении их согласованности и совместимости, это работает. И я видел это сделано. Я повторю, однако, пространство имен во многом совпадает, а не просто имя класса / интерфейса .

Это два подхода, которые я использовал, оба с большим успех. Я слышал, что некоторые команды используют один репозиторий с папками для каждого сервиса. Имеет смысл, современный CI / CD может отслеживать изменения пути и только создавать / развертывать измененные сервисы. Поэтому я думаю, что это третий вариант, вместо создания множества хранилищ для тесно связанных служб.