В разработке часто возникает похожая ситуация: полезный юзерам код со всех сторон окружён породой инфраструктуры, конвертеров данных и легаси. На помощь приходит микросервисная архитектура: огромную глыбу можно раздробить на кусочки, в каждом из которых камня поменьше, а полезного кода — побольше.
Мы предлагаем разработчикам .NET и Java поддаться золотой лихорадке: посмотрим, кто лучше добывает полезный код из монолита. Присоединяйтесь к своей команде и работайте на общую победу: в зачёт идёт каждый правильный ответ.
В разработке часто возникает похожая ситуация: полезный юзерам код со всех сторон окружён породой инфраструктуры, конвертеров данных и легаси. На помощь приходит микросервисная архитектура: огромную глыбу можно раздробить на кусочки, в каждом из которых камня поменьше, а полезного кода — побольше.
Мы предлагаем разработчикам .NET и Java поддаться золотой лихорадке: посмотрим, кто лучше добывает полезный код из монолита. Присоединяйтесь к своей команде и работайте на общую победу: в зачёт идёт каждый правильный ответ.
Комментарии (9)
hello_my_name_is_dany
12.05.2022 23:29+6Итак, теперь монолит может быть расколот, а золотые самородки почти у вас в руках! Но подобно тому, как золото нужно потом собрать вместе, чтобы победно в нём искупаться, так и микросервисы всё ещё остаются частью единого целого.
Как будем обеспечивать взаимодействие между ними? Выберите самый распространённый в микросервисной архитектуре способ.
Взаимодействие зависит от бизнес-процессов. Что-то можно асинхронно (очереди, брокеры), а что-то нужно синхронно (api, rpc). События лучше через шину передавать, а что-то получить проще через http. Мне кажется, что синхронный самый распространённый, так как это проще и быстрее сделать. Довольно холиварный вопрос
Enfriz
13.05.2022 01:15+6Как я понимаю, речь идёт в основном про теорию, превалирующую в литературе по .NET микросервисам. Там что ни книжка, то шина событий. В реальной жизни все мы знаем, что сервисы могут и в БД друг к другу залезать если очень нужно :)
XaBoK
|А какие из перечисленных принципов SOLID уменьшают запутанность системы и увеличивают изолированность её модулей?|А вот и нет. Принцип открытости/закрытости говорит скорее о правильности использования сокрытия, а не о том, насколько модульной получится конечная система.После первого же вопроса решил дальше не продолжать. Если Open/Closed не способствует изолированности модуля, то пожалуй у нас разное понимание этого термина.
Enfriz
Open/Closed он же про наследование. А в модульных структурах composition over inheritance. Можно сделать жёстко сцепленный монолит, почти не нарушающий open/closed.
XaBoK
Полиморфный вариант не единственный. Для меня приоритетным прочтением будет принцип открытости/закрытости Мейера: A module will be said to be closed if [it] is available for use by other modules.
Собственно, при закрытости модуля, его изменения и расширения не влияют на другие модули. Если пойти от обратного, то отсутствие изолированности - это когда при изменениях модуля А необходимо изменить модуль Б.
Достигается это обычно через полиморфный принцип, введением абстракции (интерфейс - реализация).
makar_crypt
абсолютно согласен.
Даже если внутри сложный адский класс , то использовать легко как , т.к. "вовне" всего 1 метод.
mySuberBilling.SPISAT_DENEG(userid, 55);Больше тебе ничего не нужно знать. Если это не "уменьшают запутанность системы и увеличивают изолированность ", то ...