Есть время собирать камни, и есть время разбрасывать. Рано или поздно, специализируясь в какой то области, например в корпоративной архитектуре, человек начинает не только и не столько стремиться к получению знаний, необходимых для ориентирования в своей области, но и делиться накопленным обобщениями. Или опытом (сыном ошибок трудных). Не миновал этот этап и меня.
Начну с «исправления имен» как базы для совершенствования (меткое наблюдение конфуцианства) на примере того, как у нас переводится базовый принцип построения микросервисной архитектуры: «low coupling and high cohession». И как понимание терминологии помогает отличить профанов, изображающих с помощью птичьего языка некое знание, от действительно понимающих суть людей.
Прежде чем переходить к качественному переводу нужно понять контекст и суть термина в исходном языке. Если кратко low coupling это про то, что изменения 1 микросервисе по возможности не должны приводить к масштабным изменениям смежных и далее по цепочке микросервисов. А high cohesion говорит нам о том, что микросервис должен целостно закрывать явно выделенный кусок бизнес контекста. т. е. чтобы изменение бизнес контекста, требующее ИТ доработок в идеале (недостижимом как горизонт), приводило к доработке одного микросервиса. т. е. микросервис не настолько мал, чтобы бизнес задача была сильно больше его, и не настолько зависим от смежников, чтобы любая задача требовала перелопачивания всего ИТ ландшафта.
Собственно в этом суть микросервисной архитектуры, когда в микросервис упаковывается самодостаточный функционал, который можно относительно независимо развивать отдельной командой, с отдельным артефактом поставки и т. д. Где то здесь должны звучать буквы DDD. Но не будем — DDD слишком обширная тема, для небольшой заметки.
