Лучшая практика для API Gradle по сравнению с реализацией в многомодульном проекте

Репост из темы Форум Gradle.

То, что вы описываете, является довольно распространенным обсуждением систем многоуровневой архитектуры, также известных как «строгие» и «свободные» слои или «открытые» и «закрытые» слои. См. эту (надеюсь, бесплатную) главу из Шаблоны архитектуры программного обеспечения для некоторых семиотических вопросов, которые вряд ли сильно помогут вам с вашим выбором.

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

Если несколько модулей должны разорвать инкапсуляцию уровня таким же образом, я могу рассмотреть возможность добавления отдельного базового модуля, раскрывающего эту функциональность, с таким именем, как base-xyz. Добавление нового модуля — это большое дело не из-за технической работы, а потому, что наш мозг может обрабатывать только определенное количество «вещей» за раз (фрагментирование). Я считаю, что то же самое будет справедливо и для «вариантов» Gradle, когда они станут доступны, но я пока не могу этого утверждать, поскольку я не пробовал их на практике.

Если всем клиентам модуля base требуется доступ к library (т. е. потому что вы используете классы или исключения из library в своих общедоступных подписях), вам следует предоставить library как зависимость API от base. Недостатком этого является то, что library становится частью общедоступного API base, и он, вероятно, больше, чем вам хотелось бы, и не находится под вашим контролем. Публичный API — это то, за что вы несете ответственность, и вы хотите, чтобы он был небольшим, документированным и обратно совместимым.

В этот момент вы можете думать о модулях jigsaw (хорошо), osgi (эээ… не стоит) или об обертывании частей lib, которые вам нужно выставить в ваших собственных классах (может быть?)

Обертывание только ради разрыва зависимостей — не всегда хорошая идея. Во-первых, это увеличивает объем кода, который вы поддерживаете и (надеюсь) документируете. Если вы начнете делать небольшие адаптации на уровне base, а library является хорошо известной библиотекой, вы вносите несоответствия (с добавленной стоимостью) - нужно всегда быть начеку, остаются ли в силе их предположения для lib. Наконец, часто тонкие оболочки в конечном итоге приводят к утечке дизайна библиотеки, поэтому, даже если они обертывают API, это все равно заставляет вас касаться клиентского кода при замене/обновлении lib, и в этот момент вам, возможно, лучше использовать lib напрямую.

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

Не зацикливайтесь на лучшем (как в «Что бы сделал дядя Боб») дизайне, когда сработает любой хороший дизайн. Количество дополнительной сложности, которое оправдано для введения порядка, является нечеткой величиной, и это то, что вы должны решить. Лучше позвони и не бойся завтра поменять :-)