Проблемы терминологии — loose coupling and high cohesion
Есть время собирать камни, и есть время разбрасывать. Рано или поздно, специализируясь в какой-то области, например, в корпоративной архитектуре, человек начинает не только и не столько стремиться к получению знаний, необходимых для ориентирования в своей области, но и делиться накопленным обобщениями. Или опытом (сыном ошибок трудных). Не миновал этот этап и меня.
Начну с «исправления имен» как базы для совершенствования (меткое наблюдение конфуцианства) на примере того, как у нас переводится базовый принцип построения микросервисной архитектуры: «loose coupling and high cohesion». И как понимание терминологии помогает отличить профанов, изображающих с помощью птичьего языка некое знание, от действительно понимающих суть людей.
Прежде, чем переходить к качественному переводу, нужно понять контекст и суть термина в исходном языке. Если кратко, loose coupling это про то, что изменения одного микросервиса по возможности не должны приводить к масштабным изменениям смежных и далее по цепочке микросервисов. А high cohesion говорит нам о том, что микросервис должен целостно закрывать явно выделенный кусок бизнес контекста. т. е. чтобы изменение бизнес контекста, требующее ИТ доработок, в идеале (недостижимом как горизонт) приводило к доработке одного микросервиса. т. е. микросервис не настолько мал, чтобы бизнес задача была сильно больше его, и не настолько зависим от смежников, чтобы любая задача требовала перелопачивания всего ИТ ландшафта.
Собственно, в этом суть микросервисной архитектуры, когда в микросервис упаковывается самодостаточный функционал, который можно относительно независимо развивать отдельной командой, с отдельным артефактом поставки и т. д. Где‑то здесь должны звучать буквы DDD. Но не будем — DDD слишком обширная тема для небольшой заметки.
Теперь, проговорив контекст, можно обсудить, как правильно перевести loose coupling and high cohesion на русский. Из контекста следует, что мы должны стремиться к понижению зависимостей на смежные команды, и повышать внутреннюю связность микросервиса. т. е. чтобы микросервис был достаточно независим и внутренне сплочен для самостоятельного плавания по волнам кровавого энтерпрайза.
Мне видится наиболее правильным перевод в стиле задачи minimax: «минимизация зависимостей и максимизация внутренней связности» микросервиса. Термин «зависимость на смежные команды» по моему опыту интуитивно понятен в ИТ среде. С точки зрения этимологии русского языка «связность» уже отсылает к чему то внутреннему, но чтобы не было разночтений, усилим до «внутренняя связность». Видится, что данный выше перевод целостен и внутренне непротиворечив и интуитивно помогает понять проблематику.
Выше написанное кажется очевидным (как минимум мне), и вроде нет повода для статьи. Но! На этой неделе опять увидел перевод: «Шаблоны GRASP: Low Coupling (низкая связанность) и High Cohesion (высокое зацепление)» некоторой конторы обучающей архитектуре. Пытливый читатель может загуглить, чтобы убедиться, что я не придумал. Я утверждаю, что если понимать контекст и смысл термина, не возможно в здравом уме переводить (не будем про то, что low это не исходное loose) «loose coupling» как » низкая связность», так как связность на русском языке про внутреннее состояние, а в исходном термине coupling про взаимоотношение со внешним по отношению к микросервису. И наоборот «зацепление» это в русском языке про взаимодействие со внешним, а «high cohesion» в исходном термине это про целостность внутренней структуры.
Предвижу обвинения в душноте. Отвечу на них тем, что «loose coupling high cohesion» это ключевой термин микросервисной архитектуры, нужный не только для внутренних дискуссий архитекторов, но и для того, чтобы пояснять держателям бюджета (людям от бизнеса), что и почему делается. И поэтому обязанный быть максимально интуитивно понятным. Держитесь подальше от тех, кто рассказывает про правильность стремления «к низкой связности и высокому зацеплению».
