Комментарии 6
А вам реально надо всякие там микросервисы и еще куча архитектурных слоев? Сделайте блин сперва что-то реально рабочее в одном монолите, а вот если реально это пойдет то тогда уже и понятно будет как это надо разбивать на микросервисы и т.д.
Как говорится "любую проблему можно решить введением дополнительного уровня абстракции. Кроме проблемы слишком большого количества уровней абстракции." :)
Вы правы. Я во многих статьях читал, что mvp должен разрабатываться как можно проще, чтобы не жалко было выкинуть. Но. Мы решили пойти своим путем. Ну реально, мы же имеем право идти и развиваться как считаем нужным. Причину почему я написал и в статьях и в ответе на ваш комментарии в предыдущей статье.
Поддерживать микросервисную архитектуру
- Уменьшает сложность реализации предметной области физически разделяя поддомены
- Позволяет в будущем параллельную и независимую разработку несколькими командами
Поддомены можно разделять и логически в монолите, необязательно границы должны быть физическими. Про несколько команд то же самое, монолит с тем же успехом тоже можно разбить на зоны ответственности.
Мне нравятся 4 причины использования микросервисов, которые озвучил Рихтер:
1. Независимое масштабирование
2. Независимый деплой
3. Можно использовать разные языки
4. Можно использовать одну либу разных версий в разных микросервисах
Поддомены можно разделять и логически в монолите...
Да это так. Так как у нас пока модульный монолит, то мы рассматривали это именно так, а обращение сделать через фасады. Но потом решили все таки добавить шину и общение через него.
Наверное одна из проблем то, что мы не смогли вовремя остановиться. Вообще, в начале предполагалось разрабатывать только отделенный предметный слой, а в остальном думали использовать то, что предлагает NestJS.
Но когда начинаешь понимать прочитанные книги, то охота это применить и закрепить на практике. Действительно, за это время мы всей командой поняли, что скрывается за SOLID, о чем говорит DDD и многое другое поднятое в статье. Когда начинали над проектом, термин REST было незнакомым (по крайней мере для меня). А тут такое. И при этом развитие шло командное. Это меня радует не меньше.
Мне нравятся 4 причины использования микросервисов, которые озвучил Рихтер:
Я во всей статье старался исходить из того, что и как я понимал. Это сделано специально, чтобы если я что то понимаю не так, то чтобы мне ткнули на это.
Поддерживать CQRS
- Разделяет запросы чтения и изменения с целью повышения быстродействия, отказоустойчивости и оптимизации ресурсов.
Важно разделять не просто запросы, но и хранилища чтения и записи. Они действительно разделялись? Например, таблица для записи и вьюха в той же таблице для чтения. Если да, то что было хранилищем для чтения и что - хранилищем для записи?
И для описания архитектуры удобно использовать C4 Model. Если бы нарисовали диаграмму компонентов (уровень 2) то не было бы вопросов про то, есть два разных хранилища на чтение и запись или нет.
Публикации
Архитектура приложения стартапа. Взгляд с высоты птичьего полета