Правильный подход к модульной архитектуре

Пример бы какой-нибудь. И определение на каком уровне происходит разбиение на модули. Это класс? Это проект? Это единица развёртывания?

Я таки считаю, что модули - это один из инструментов управления сложностью и предложенный подход не является единственной причиной создания модуля.

Не уверен, что русское слово "модуль" в переводе используется удачно, модули могут использоваться и без намерения создавать семейство продуктов. Во многих энтерпрайз-системах логирование или аналитика выделены в отдельный модуль, но не потому что всерьез предполагается его замена в случае изменившихся требований, а просто потому что его не хочется собирать и деплоить с каждым релизом.

Эта статья строится на двух простых идеях:

• Каждое решение при проектировании программного продукта определяет пространство возможных вариантов на более поздних этапах. Это критически важно для понимания того, как и в какой последовательности стоит подходить к принятию проектных решений.

• Модули можно использовать для сохранения неопределённости в ключевых узлах, чтобы оставить больше свободы в дальнейшем.

Мне кажется, точне даже не кажется, я в этом уверен - каждое решение имеет ценность, если оно принято вовремя. Т.е. прекрасно оставлять себе пространство для маневра, но истинную ценность мы имеем, когда принимаем решения вовремя. А если мы этого не делаем, часто это множит на ноль "правильность" принятого решения

Второй момент, модульность базово дает следующее:

• формализирует связи и зависимости внутри приложения, так как если у вас один большой модуль, то следить за этим тяжелее

• позволяет использовать это знания для того, чтобы внося изменения точно оценивать уровень влияния и строить стратегию тестирования (ну и делать это лучше и быстрее)

• явно "скрывать" логику реализации от других модулей, разделяя модуль на конкракт сервиса (белый ящик) и реализацию (черный ящик)

• использовать наилучшие технологичные решения для конкретного модуля

У вас с самого начала некие вторичные свойства поставлены во главу, хотя ... они скорее как последний вагон в поезде. Модульность сразу определяет очертания контрактов и задает, что мы кодим. Если вы поделили на модули неудачно - это большая пичалька и возможно, вас ждет большой рефакторинг и перенос кода туда-сюда. Более того, если вам надо начинать кодить (вспоминаем про своевременность принятия решения) - основные технологические решения надо принимать уже вчера. Никакой гибкости у вас нет, кроме как поменять что-то внутри модуля. Ну либо сначала пойти на PoC, чтобы нащупать лучший путь для вас и потом уже по нему бежать, особо не оглядываясь

Дерево принятия решения, да и вообще основные решения принимаются на этапе проектирования системы, базируясь на собранных нефункциональных требованиях и скелете функциональных требований. Все что вы оставляете на "потом" - это открытые вопросы с четко очерченными вариантами и способом, как выбрать тот один, по которому комадна пойдет дальше

Все сокрытие, о котором вы пишете, сводится к пределоно простой вещи. Контракт и реализация. Реализация - черный ящик, который скрыт от остальных. Но как только вы начинаете его кодить, вы его открываете для себя и тут же принимаете решения. Но они формально могут остаться скрытыми от других модулей, если вам так нравится считать.

Хорошая статья, но хочется "придраться" к одной фразе:

• Мы не делим наше программное обеспечение на два модуля, потому что над ним будут работать две команды.

Как раз таки в этом случае я бы разделил. Две команды, с разными бэклогами, стилями кодирования - хорошая причина для разделения. Тут конечно вопрос, что понимается под модулем...