Разделение прикладных уровней в различные блоки

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

Оттуда, попытайтесь уменьшить блоки до вещей, которые имеют смысл к версии независимо. Если всегда необходимо копировать более чем 10 блоков вместе, то они, вероятно, должны быть созданы как один.

DLLs или блоки являются единицами распределения.

1. Если код в конкретном пространстве имен или классе так сильно связывается с другим пространством имен или классом затем, это должно быть в той же единице распределения. Если код в нечто.* файл никогда не будет использоваться, не нуждаясь в коде в панели.* файл затем можно также встроить их в ту же единицу распределения.
2. Если пространство имен или группа классов представляют допускающий повторное использование компонент (т.е. тот код используется в двух или больше продуктах/приложениях), затем, это - хороший кандидат для отдельного управления версиями и является его собственной единицей распределения.

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

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

Мы не стараемся изо всех сил пихать код в блок, которого он не принадлежит. Но мы определенно не создаем новый блок без веской причины того, чтобы сделать так. Обычно у нас есть блок для общей логики приложения (бизнес-объекты, и т.д.) и блок для пользовательского интерфейса (веб-блок, блок WinForms, и т.д.). Мы также не копируем код / классы среди блоков только, чтобы не создавать новый блок.