AS
То есть, опираясь на SRP мы вряд ли сможем выровнять ИТ с бизнесом
В моей практике, совместное использование микросервисов и бизнес-процессов как раз создавало "гибкие" решения. Бизнесу очень понравилось.
Size: a a a
2017 May 29
MS
Коллеги, пойду постараюсь исправить видео сегодняшнего вебинара. Еще раз спасибо за обсуждение
GK
Alexander Samarin
В моей практике, совместное использование микросервисов и бизнес-процессов как раз создавало "гибкие" решения. Бизнесу очень понравилось.
В моей практике тоже, но при чём здесь SRP?
GK
SRP - это про дизайн классов, воообще-то
GK
Бизнес бежит туда где "гибче", а не туда - где "правильней"( с точки зрения IT-архитектуры). И это тренд
+1
GK
С другой стороны, понятие ограниченного контекста не чёткое, он может быть довольно большим. Ограниченный контекст может всключать в себя разные сервисы, каждый из которых может иметь собственный жизненный цикл. Пример, который привёл Максим, новый сервис, с которым пришёл бизнес. Видимо нет высеченных в камне рекомендаций о границах микросервисов, либо нужно вводить дополнительные понятия отражающие разные масштабы сервисов.
AS
SRP - это про дизайн классов, воообще-то
ну-ну, а если вспомнить классические производственные конвейеры?
GK
Допустим, они часто меняются?
AS
Допустим, они часто меняются?
Ну конечно, так Мерседес, который выпускает много моделей, не успевает перепрограммировать своих роботов.
GK
Сервис может реализовать несколько логических связанных функций, будет соблюдаться high cohesion, но нарушаться SRP. Так что, на мой взгляд, нет какого-то одного принципа, согласно которому можно очертить границы сервиса/микросервиса. Наверно можно попробовать выделить критерии, котрым соотвествует микросервис. Может быть модель зрелости. Максим в сегодняшнем вебинаре приблизился к решению этой задачи, описав кейсы, в которых нужны микросервисы.
AS
Сервис может реализовать несколько логических связанных функций, будет соблюдаться high cohesion, но нарушаться SRP. Так что, на мой взгляд, нет какого-то одного принципа, согласно которому можно очертить границы сервиса/микросервиса. Наверно можно попробовать выделить критерии, котрым соотвествует микросервис. Может быть модель зрелости. Максим в сегодняшнем вебинаре приблизился к решению этой задачи, описав кейсы, в которых нужны микросервисы.
Ну дальше обсуждать будет непросто, так как я не знаю какие определения концепций "сервис" и "функция" Вы используете.
GK
Alexander Samarin
Ну дальше обсуждать будет непросто, так как я не знаю какие определения концепций "сервис" и "функция" Вы используете.
Сожалею
AS
Это будет следующий вопрос к Максиму - нминимальная терминология по теме.
K
При столь общих определениях и столь разных концепциях, закладываемых в слово "микросервис", что только сегодня прозвучали в этом чате, странно расчитывать на какую-то определенность.
K
Лучше сначала согласовывать определения этого слова, а потом уже обсуждать детали.
MS
Сервис может реализовать несколько логических связанных функций, будет соблюдаться high cohesion, но нарушаться SRP. Так что, на мой взгляд, нет какого-то одного принципа, согласно которому можно очертить границы сервиса/микросервиса. Наверно можно попробовать выделить критерии, котрым соотвествует микросервис. Может быть модель зрелости. Максим в сегодняшнем вебинаре приблизился к решению этой задачи, описав кейсы, в которых нужны микросервисы.
По большому счету это одна из причин, почему микросервисы не слишком удачный выбор сразу же для новой предметной области. Менять границы микросервисов в будущем представляется очень сложным с учётом именно технологических особенностей.
AS
Как мы уже видели, одним слово тут не обойдется. Мое определение есть в http://improving-bpm-systems.blogspot.ch/2017/05/beauty-of-microservices-ebanliing.html
GK
По большому счету это одна из причин, почему микросервисы не слишком удачный выбор сразу же для новой предметной области. Менять границы микросервисов в будущем представляется очень сложным с учётом именно технологических особенностей.
Максим, боюсь, всё сложнее. Чтобы менять границы их нужно иметь. Видимо, должны быть какие-то характеристики, признаки, по которомы можно выделить микросервисы.
MS
Максим, боюсь, всё сложнее. Чтобы менять границы их нужно иметь. Видимо, должны быть какие-то характеристики, признаки, по которомы можно выделить микросервисы.
Я о том и говорю, что любые критерии, используемые сейчас, слишком частные. И коль скоро бизнес функции меняются, то эти границы бизнеса тоже могут меняться, что не очень удобно в текущей реализации, мягко говоря