День 1244. #Оффтоп Закон Конвея, DDD и Микросервисы Закон Конвея гласит, что «любая организация, проектирующая систему, создаст проект, структура которого является копией коммуникационной структуры организации». Это оказывает существенное влияние на то, как создаётся ПО, особенно если применяются микросервисы и/или предметно-ориентированное проектирование (DDD). Мел Конвей заметил, что отдельным организационным единицам или командам в рамках крупной организации при совместной работе над крупной системой приходится разбивать эту систему на части, над которыми каждая из команд может работать настолько независимо, насколько это возможно. Затем они выясняли, как две системы будут взаимодействовать друг с другом через какой-либо канал коммуникации. Таким образом структура системы отражала структуру организации. В небольших организациях это может быть меньше выражено. Когда людей немного, вам не нужны отдельные команды и каналы связи. Вы можете построить систему, используя любые методы декомпозиции, которые имеют смысл для системы и её архитектуры. Но по достижении определённого предела оказывается, что очень неэффективно, когда разные команды работают над одним модулем, и объём дополнительных затрат на коммуникации быстро растёт. В DDD идея ограниченного контекста используется для обеспечения инкапсуляции в системе. В этом контексте применяется определённый набор предположений, единый язык и отдельная модель предметной области. Очевидно, рекомендуется наличие корреляции между командами и ограниченными контекстами, так как в противном случае очень легко нарушить инкапсуляцию и применить неправильные предположения, язык или модель в заданном контексте. Микросервисы очень хорошо сопоставляются с ограниченными контекстами, и это одна из причин, по которой в них часто применяется DDD. Чтобы быть по-настоящему независимым от других частей системы, микросервис должен иметь собственный конвейер сборки, собственную инфраструктуру хранения данных и т. д. Во многих организациях за отдельный микросервис отвечает отдельная команда. Было бы странно и неэффективно иметь микросервис, за поддержку и развёртывание которого несёт ответственность несколько разных команд. Всё это означает, что, если вы крупная организация, ваша организационная структура оказывает значительное влияние на архитектуру распределённых систем, которые вы создаёте и поставляете. Вы не можете ожидать, что ваш технический директор или ведущий архитектор сядут в комнате с вашими лучшими техническими специалистами, спроектируют систему на доске, а затем ваша существующая организация просто поделит работу и выполнит её. Скорее всего, дизайн системы будет (или должен) влиять на организацию самих команд, и в какой-то степени наоборот. В ПО есть много проблем, которые не обязательно являются проблемами собственно ПО. Многие проблемы с поставкой больших и сложных систем связаны с проблемами коммуникаций, людей, менеджмента. Часто технари и управленцы идут разными дорогами в своей карьере, и это приводит к разрыву между тем, как система должна быть спроектирована с технической точки зрения, и тем, как организация структурирована с точки зрения команд и структуры отчетности. Исправление этого несоответствия может иметь большее значение для успеха системы, чем многие другие решения в области технической архитектуры или практик кодирования. Классический комикс ниже иллюстрирует некоторые крупные компании и их (предполагаемые) проблемы с организационной структурой. Итого Понимание закона Конвея и его влияния на проектирование больших систем важно, если вы собираетесь распознавать проблемы, связанные с организацией команд. То, как вы разбиваете большую проблему и настраиваете коммуникации между модулями, должно влиять на то, как вы организуете команды, и, если эти команды не согласуются с программными модулями, которые вы создаёте, у вас возникнут проблемы. Чем раньше эти проблемы будут обнаружены и исправлены, тем больше шансов на общий успех системы и, в конечном счёте, организации. Источник: ardalis.com/conways…services