Архитектура, которую вы описываете, является наилучшей практикой, обеспечивающей возможность повторного использования, модульности и масштабируемости. Но можно потерять равновесие, достигнув этих целей. Одной из вещей, на которые нужно обратить внимание, является необходимость разделения и размера вертикального стека Business Logic - DAL. Посмотрите на ваши модули и попробуйте найти вескую причину , почему отдельные модули отделены друг от друга. Они должны быть развернуты отдельно у клиента для масштабируемости или проданы отдельно?
Если вы не можете найти хорошее обоснование для вертикального разделения, вы можете объединить некоторые модули и получить больший модуль, который может совместно использовать BL и DAL. Зернистость модулей увеличивается, уменьшая накладные расходы.
Также можно рассмотреть горизонтальное разделение, которое вы упомянули между BL и DAL, но оно определенно служит для возможности отделить логику от части данных, которые обычно развертываются на отдельных уровнях в крупномасштабной среде. Возможность вызова BL-модуля всеми необходимыми модулями DAL возможна, но делает масштабирование базы данных более сложным при использовании с сопоставителями Entity DB, поскольку при поддержке таблиц на нескольких серверах придется поддерживать несколько соединений с базами данных.
Таким образом, мой личный подход состоит в том, чтобы начать смотреть на гранулярность ваших комбинаций BL - DAL и посмотреть, сможете ли вы комбинировать некоторые из них, уменьшая свои накладные расходы, не теряя при этом большую часть хороших вещей. И если у вас есть все эти модули, я думаю, вы могли бы распараллелить сборку для группы модулей. Это преимущество вашей модульной архитектуры, от которого вы можете извлечь выгоду. Почему нет?