Всем привет!
Недавно собеседовал человека.
Кандидат мне заявил, что можно Domain(я про DDD) разбить на несколько сборок(при условии, что сущности в них не связаны).
Я подумал, да можно, в принципе.
Но как-то это странно выглядит, еще ни в одном проекте такого не видел, чтобы домен был представлен несколькими сборками.
Что вы думаете по поводу разбиения домена на несколько сборок?

А в чем собственно проблема... DDD это логическое разбиение, никто не мешает физически размещать хоть по классу на сборку.

Jonie, да, никто не мешает, я согласен и что разместить можно тоже согласен.
Но как ни странно, я ни разу не видел проекты, чтобы такое разбиение(физическое) происходило.
Меня это заинтересовало.
А вообще вопрос возник из того, что я спросил у кандидата
правильна ли будет запись class A:I,B(где I - это интерфейс)
на это кандидат ответил, что такое знать необязательно, ибо есть компилятор.
я спросил, а если проект будет компилироваться 20 минут?
он ответил, тогда для удобства компиляции разобьем вот на несколько сборок домен.
я подумал, почему бы и не разбить - ничему это не противоречит, но за свою практику такого не припомнил.

какой-то унылый вопрос, джуниорный... и вообще жутко выводящие из себя вопросы вида "будет ли компилироваться".


я видел и далеко не один, особо в компаниях где над проектом работают не одна группа разрабов.

Ну искали и жуниора...
Просто чтобы было правильно понятно, допустим структура проекта такая(по сборкам):
Project.Domain
Project.Data
Project.Client

я ни разу не видел, даже в больших проектах, чтобы сборку Project.Domain дробили на Project.Domain1, Project.Domain2 и т.д.
Я не отрицаю что это возможно, и не говорю, что это неправильно, просто вот не видел такого почему-то... хотя и принимал участие в больших проектах.

погуглил
http://stackoverflow.com/questions/2054306...assemblies?rq=1
тут этим недовольны товарищи программисты.

Я в этом ниче такого не вижу, но т.к. не сталкивался с таким разбиением на практике, смущает.
Вот когда такое разбиение оправдано?

Это сообщение отредактировал(а) AntiInt - 11.3.2014, 12:04

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


Вообще сборки - это физическое представление структуры решения. А логическим являются неймспейсы.
Соответственно разделение на сборки будет оправдано тогда, когда требуется физически разнести код на модули - например та же компиляция, или вам необходимо во время выполнения подключать дополнительные части домена (возможно написанные сторонними разрабами), или у вас какой-нибудь мега-тонкий клиент, который тянет с сети только самые необходимые сборки, остальные - по мере надобности.
Имхо - физически можно делить хоть как, зависит от соответствующих требований, а логически - можно весь домен содержать в одном неймспейсе (например MyPropject.Domain), тип размещенный в неймспейсе MyProject.Domain.Department1 - соответственно тоже относится к домену. Тип из MyProject.Data - относится уже к данным, даже если лежит с доменными типами в одной сборке\файле.

тут как раз писалось вот "I want to put each of which sub domains into a separate assembly (I wanna split it into 1st:vertical 2nd: horizontal  modules => easy reusability)."
Если смотреть в терминах ddd, то разделение возможно на контексты, а тут по сборкам разнести.
По остальным пунктам с Вами согласен(на данный момент не встречал такое в проектах, видать не было необходимости в таком дроблении).
И по поводу подгружаемых сущностей, которые написаны сторонними разрабами - тут спорный вопрос, т.к. это уже получается система плагинизации, а следовательно интерфейсы подгружаемых объектов уже есть в домене.
И что касается тонкого клиента - тут есть более правильное решение(описано у рихтера) по поводу подгружаемых сущностей - использование сборок состоящих из нескольких объектных модулей
(файлы с расшиением .netmodule) они как раз и используются для динамической подгрузки, хотя и длл можно подгрузить...
другой вопрос стоит ли делить сборку Project.Domain на сборки Project.Domain1 и Project.Domain2 только из-за компиляции?

Виноват, не увидел.


Плагины - это частный случай.


Согласен, не очень удачный пример, хотя опять же зависит от приложения - если вы в сервисе влк\выкл отдельные большие фичи, то возможно удобней вообще не деплоить сборку (и не показывать лишних метаданных).

Кстати говоря про компиляцию - нетмодули тут тоже могут помочь, т.к. могут быть скомпилены по-отдельности (читай - параллельно) и затем слинкованы, также можно шибко шареный и больошй код компилить в отдельный модуль и затем линковать во все сборки, где он нужен, а не компилить много раз для каждой сборки. Но прежде, чем так изголяться, мне кажется надо провести соответствующие замеры - стоит ли овчинка выделки, т.к. в Студии по-моему модули не поддерживаются вообще, так что придется шаманить с собственными msbuild-тасками и работать непосредственно с компиляторами и линкером. Плюс с версиями больше заморочек. Если полученный выигрыш во времени компиляции того не стоит - нафиг надо ))

Это сообщение отредактировал(а) dzaraev - 12.3.2014, 06:35

Да, студия нетмодули не поддерживает, тут надо AL.exe, придется мсбилд или нант использовать.
А разве метаданные будут видны если нетмодуль не прилинкован? нетмодуль же сам содержит метаданные и код.
Все же давайте вернемся к теме,
на сколько оправдано дробление домена и вообще нужно ли оно?
Или же допостовляемые сущности - это уже контекст, который может и должен быть в отдельной сборке.

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


По теме я ответил (касательно компиляции):


Подробнее не подскажу, в теории DDD не силён. Скажу только, что разбивать что-то большое на составляющие - это общее эмпирическое правило в программировании. И еще напомню - что сборки тут не при чем (ИМХО), это физический уровень (точнее логическая организация физического представления вашей программы). Нужно решать физ. задачу - шаманьте со сборками\нетмодулями. Нужно логически отделить мух от котлет - неймспейсов вполне достаточно.