| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Общие вопросы по .NET и C# > Domain в нескольких сборках |
| Автор: AntiInt 11.3.2014, 09:02 |
| Всем привет! Недавно собеседовал человека. Кандидат мне заявил, что можно Domain(я про DDD) разбить на несколько сборок(при условии, что сущности в них не связаны). Я подумал, да можно, в принципе. Но как-то это странно выглядит, еще ни в одном проекте такого не видел, чтобы домен был представлен несколькими сборками. Что вы думаете по поводу разбиения домена на несколько сборок? |
| Автор: jonie 11.3.2014, 11:03 |
| А в чем собственно проблема... DDD это логическое разбиение, никто не мешает физически размещать хоть по классу на сборку. |
| Автор: AntiInt 11.3.2014, 11:10 |
| Jonie, да, никто не мешает, я согласен и что разместить можно тоже согласен. Но как ни странно, я ни разу не видел проекты, чтобы такое разбиение(физическое) происходило. Меня это заинтересовало. А вообще вопрос возник из того, что я спросил у кандидата правильна ли будет запись class A:I,B(где I - это интерфейс) на это кандидат ответил, что такое знать необязательно, ибо есть компилятор. я спросил, а если проект будет компилироваться 20 минут? он ответил, тогда для удобства компиляции разобьем вот на несколько сборок домен. я подумал, почему бы и не разбить - ничему это не противоречит, но за свою практику такого не припомнил. |
| Автор: jonie 11.3.2014, 11:47 | ||||
какой-то унылый вопрос, джуниорный... и вообще жутко выводящие из себя вопросы вида "будет ли компилироваться".
я видел и далеко не один, особо в компаниях где над проектом работают не одна группа разрабов. |
| Автор: AntiInt 11.3.2014, 12:00 |
| Ну искали и жуниора... Просто чтобы было правильно понятно, допустим структура проекта такая(по сборкам): Project.Domain Project.Data Project.Client я ни разу не видел, даже в больших проектах, чтобы сборку Project.Domain дробили на Project.Domain1, Project.Domain2 и т.д. Я не отрицаю что это возможно, и не говорю, что это неправильно, просто вот не видел такого почему-то... хотя и принимал участие в больших проектах. погуглил http://stackoverflow.com/questions/20543066/ddd-break-the-domain-into-sub-domains-in-different-assemblies?rq=1 тут этим недовольны товарищи программисты. Я в этом ниче такого не вижу, но т.к. не сталкивался с таким разбиением на практике, смущает. Вот когда такое разбиение оправдано? |
| Автор: dzaraev 11.3.2014, 14:51 | ||||
Тут вроде бы не о сборках речь, а о разделении самого домена на составляющие (логически).
Вообще сборки - это физическое представление структуры решения. А логическим являются неймспейсы. Соответственно разделение на сборки будет оправдано тогда, когда требуется физически разнести код на модули - например та же компиляция, или вам необходимо во время выполнения подключать дополнительные части домена (возможно написанные сторонними разрабами), или у вас какой-нибудь мега-тонкий клиент, который тянет с сети только самые необходимые сборки, остальные - по мере надобности. Имхо - физически можно делить хоть как, зависит от соответствующих требований, а логически - можно весь домен содержать в одном неймспейсе (например MyPropject.Domain), тип размещенный в неймспейсе MyProject.Domain.Department1 - соответственно тоже относится к домену. Тип из MyProject.Data - относится уже к данным, даже если лежит с доменными типами в одной сборке\файле. |
| Автор: AntiInt 11.3.2014, 15:08 |
| тут как раз писалось вот "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 только из-за компиляции? |
| Автор: dzaraev 12.3.2014, 06:29 | ||||||
Виноват, не увидел.
Плагины - это частный случай.
Согласен, не очень удачный пример, хотя опять же зависит от приложения - если вы в сервисе влк\выкл отдельные большие фичи, то возможно удобней вообще не деплоить сборку (и не показывать лишних метаданных). Кстати говоря про компиляцию - нетмодули тут тоже могут помочь, т.к. могут быть скомпилены по-отдельности (читай - параллельно) и затем слинкованы, также можно шибко шареный и больошй код компилить в отдельный модуль и затем линковать во все сборки, где он нужен, а не компилить много раз для каждой сборки. Но прежде, чем так изголяться, мне кажется надо провести соответствующие замеры - стоит ли овчинка выделки, т.к. в Студии по-моему модули не поддерживаются вообще, так что придется шаманить с собственными msbuild-тасками и работать непосредственно с компиляторами и линкером. Плюс с версиями больше заморочек. Если полученный выигрыш во времени компиляции того не стоит - нафиг надо )) |
| Автор: AntiInt 12.3.2014, 08:16 |
| Да, студия нетмодули не поддерживает, тут надо AL.exe, придется мсбилд или нант использовать. А разве метаданные будут видны если нетмодуль не прилинкован? нетмодуль же сам содержит метаданные и код. Все же давайте вернемся к теме, на сколько оправдано дробление домена и вообще нужно ли оно? Или же допостовляемые сущности - это уже контекст, который может и должен быть в отдельной сборке. |
| Автор: dzaraev 12.3.2014, 10:47 | ||||||
Если не прилинкован - не будут, но вы же предлагали сценарий где грузятся нетмодули с сервера - они-то уже слинкованы, и все метаданные со всех модулей будут известны по манифесту сборки, который в любом случае обязательно будет загружен в вашем сценарии, иначе CLR не будет знать - где какие типы лежат в каких модулях. Сам нетмодуль содержит только метаданные своих типов и ссылки на другие модули, если юзает их типы. Манифест сборки содержит метаданные по всем типам и в каких модулях они лежат и ссылки на все нетмодули, он исчерпывающе описывает всю сборку, даже если она разбита на файлы и он обязательно будет сразу загружен с сервера, чтобы clr могла вообще работать с данной сборкой.
По теме я ответил (касательно компиляции):
Подробнее не подскажу, в теории DDD не силён. Скажу только, что разбивать что-то большое на составляющие - это общее эмпирическое правило в программировании. И еще напомню - что сборки тут не при чем (ИМХО), это физический уровень (точнее логическая организация физического представления вашей программы). Нужно решать физ. задачу - шаманьте со сборками\нетмодулями. Нужно логически отделить мух от котлет - неймспейсов вполне достаточно. |
