AN
вангую - чтобы добавить поле в формочку - надо будет сделать 5 коммитов в разные репозитории =\
еще не дошли до этого, но вполне может быть. Тут все плюсы и минусы мироксервсисной архитектуры.
Size: a a a
2020 November 27
SZ
Выделили зоны ответсвенности, границы сервисов, сформировали команды и пилим. Или в чем вопрос? Попутно меняется UI монолита
если там все плохо, то немного непонятно как вы распутали все спагетти чтобы без боли хоть что-то выделить сложнее библиотечки
SZ
типа на бумаге границы сервисов нарисовать много ума не надо. а реальность жестокая) особенно в спагетти
SZ
как у вас новые сервисы интегрируются со старым кодом? напилили там доп апиху для внутр общения, или напрямую в базу ходят?
AN
просто непонятно, если нет проблемы с выделением границ сервисов - зачем уходить с монолита
надо просто на код посмотреть чтобы понять. Там много причин, например Оракл в качестве БД, лицензии на него покупать не хочется. В самом приложении куча точек входа. Мешанина php и js. Отсутствие composer, где то даже в папке просто часть на Kohana написана.
k
еще не дошли до этого, но вполне может быть. Тут все плюсы и минусы мироксервсисной архитектуры.
просто микросервисы - это про low coupling high cohesion, это в свою очередь очень влияет на умение писать нормальные тесты, а вы тесты не пишете, вероятно потому, что не особо умеете. Поэтому такие сомнения
SZ
просто микросервисы - это про low coupling high cohesion, это в свою очередь очень влияет на умение писать нормальные тесты, а вы тесты не пишете, вероятно потому, что не особо умеете. Поэтому такие сомнения
вроде говорили в новом коде пишут
AN
просто микросервисы - это про low coupling high cohesion, это в свою очередь очень влияет на умение писать нормальные тесты, а вы тесты не пишете, вероятно потому, что не особо умеете. Поэтому такие сомнения
в сервисах пишем
k
вроде говорили в новом коде пишут
а, ну тогда может быть.
Но просто это опять истории про единорогов в которых я не оч верю =\
Но просто это опять истории про единорогов в которых я не оч верю =\
AN
как у вас новые сервисы интегрируются со старым кодом? напилили там доп апиху для внутр общения, или напрямую в базу ходят?
по разному. Кто то пока что в Бд ходит, кто то через апи, сервисы между собой только по API. Тут только начало пути.
k
надо просто на код посмотреть чтобы понять. Там много причин, например Оракл в качестве БД, лицензии на него покупать не хочется. В самом приложении куча точек входа. Мешанина php и js. Отсутствие composer, где то даже в папке просто часть на Kohana написана.
непонятно как все эти проблемы решают микросервисы 🤔
SZ
по разному. Кто то пока что в Бд ходит, кто то через апи, сервисы между собой только по API. Тут только начало пути.
тогда все ясно)
k
по разному. Кто то пока что в Бд ходит, кто то через апи, сервисы между собой только по API. Тут только начало пути.
"сервисы между собой только по API"
ХЗ, вы уже проиграли =\
ХЗ, вы уже проиграли =\
AN
"сервисы между собой только по API"
ХЗ, вы уже проиграли =\
ХЗ, вы уже проиграли =\
почему?
VS
по разному. Кто то пока что в Бд ходит, кто то через апи, сервисы между собой только по API. Тут только начало пути.
!ff
SZ
почему?
ну типа, если нужен кусок данных оно полезет каскадом по всем сервисам? эдакий распределенный монолит?
AN
Типа распределенных транзакций не бывает? Все же эту боль чувствуют в микросервисах, разве нет?
k
почему?
потому что пошарили данные. High coupling между сервисами.
SZ
а, ну тогда может быть.
Но просто это опять истории про единорогов в которых я не оч верю =\
Но просто это опять истории про единорогов в которых я не оч верю =\
я пока слабо представляю как можно без жесткого рефакторинга код базы писать рядом новый сервис, и при этом он будет достаточно независим
точнее даже не новый сервис, а извлечь старый
точнее даже не новый сервис, а извлечь старый