DDD, что означают все термины для водопроводчика Джо, который не может позволить себе читать книги несколько раз? - PullRequest
1 голос
/ 10 июля 2010

У меня плотный график работы над проектом, поэтому у меня нет времени читать книги, чтобы понять его.

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

Я уже знаю термины в целом, но не могу выразить их в терминах C # Project.

Ниже приведены термины, которые я до сих пор знал из прочтения краткого описания, связанного с проектом C #.Как и для чего это нужно в проекте C #.

  • Сервисы
  • Фабрики
  • Хранилище
  • Агрегаты
  • DomainObjects
  • Инфраструктура

Я действительно озадачен инфраструктурой, репозиторием и сервисами Когда использовать сервисы и когда использовать репозиторий?

Пожалуйста, дайте мне знать, если я смогу сделатьэтот вопрос более понятен

Ответы [ 4 ]

5 голосов
/ 10 июля 2010

Я рекомендую вам быстро прочитать книгу , управляемую доменом, из infoq, она короткая, бесплатная в формате PDF, которую вы можете скачать прямо сейчас, и приложит все усилия, чтобы обобщить концепции, представленные в Синяя Библия Эрика Эвана

Вы не указали, на каком языке / фреймворке находится проект, над которым вы работаете в данный момент. Если это проект .NET, посмотрите хороший исходный код для CodeCampServer .

Существует также более сложный пример с именем Fohjin.DDD , на который вы можете посмотреть (он фокусируется на концепциях CQRS, которые могут быть больше, чем вы ищете)

Стив Болен также выступил с докладом перед аудиторией alt.net по DDD, видео можно найти по ссылкам из его сообщения в блоге

Я только что опубликовал сообщение в блоге , в котором перечислены эти и некоторые другие ресурсы.

Надеемся, что некоторые из этих ресурсов помогут вам быстро начать работу.

2 голосов
/ 23 июля 2010

DDD, что означают все термины для водопроводчика Джо, который не может позволить себе читать книги несколько раз?

Я бы сказал - немного.Не достаточно точно.

2 голосов
/ 17 июля 2010

Это мое понимание, и я НЕ прочитал любую книгу DDD, даже ее священную библию.

  • Службы - классы без состояний, которые обычно работают с различными объектами слоя,таким образом помогая отделить их;также, чтобы избежать дублирования кода
  • Фабрики - классы, которые знают, как создавать объекты, таким образом, отделяя вызывающий код от знания деталей реализации, облегчая переключение реализаций;многие фабрики также помогают автоматически разрешать объектные зависимости (контейнеры IoC);фабрики - это инфраструктура
  • Repository - интерфейсы (и соответствующие реализации), которые сужают доступ к данным до минимума, который клиенты должны знать о
  • Aggregates - классах, которые объединяют доступ к нескольким связанным объектам через отдельные интерфейсы (например, порядок и позиции)
  • Доменные объекты - классы, которые работают исключительно на предметной / бизнес-логике и не заботятся о постоянстве, представлении или других проблемах
  • Инфраструктура - классы / слои, которые склеиваютразные объекты или слои вместе;содержит фактические детали реализации, которые вообще не важны для реального приложения / пользователя (например, как данные записываются в базу данных, как форма HTTP отображается для просмотра моделей).

Хранилище предоставляет доступ к оченьконкретный, обычно одиночный, вид предметного объекта.В некоторой степени они эмулируют коллекцию объектов.Сервисы обычно работают с объектами очень разных типов, к которым обычно обращаются статическими методами (не имеют состояния), и могут выполнять любые операции (например, отправлять электронную почту, готовить отчет), тогда как репозитории концентрируются на методах CRUD.

1 голос
/ 10 июля 2010

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

На высоком уровне DDD - это разложение вашего решения на уровни и четкое распределение обязанностей. Если вы попытаетесь сделать это в своем приложении, вы, вероятно, получите некоторую выгоду. Позже, когда у вас будет больше времени для учебы, вы можете обнаружить, что вы не совсем поняли все детали подхода DDD - я не вижу в этом проблемы, вы, вероятно, уже получили некоторую выгоду от продуманной структуры, даже если вы отклонился от некоторых указаний DDD.

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

Говорят об услугах:

Некоторые понятия из области не естественно моделировать как объекты. форсирование необходимая функциональность домена для быть ответственностью СУЩЕСТВА или ЗНАЧЕНИЕ либо искажает определение на основе модели объекта или добавляет бессмысленные искусственные объекты.

Поэтому: когда значительный процесс или преобразование в домен не естественная ответственность сущности или VALUE OBJECT, добавьте операцию к модель как самостоятельный интерфейс объявлен как СЕРВИС.

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

Вы должны ожидать, что экспериментируете с идеями, иногда ошибаетесь, а затем задумываетесь, почему ваши решения вредят или работают. Ваша цель должна заключаться не в том, чтобы делать DDD ради себя, а в том, чтобы производить хорошее программное обеспечение. Если вам сложно что-то реализовать или сложно что-то поддерживать, подумайте, почему это так, а затем изучите то, что вы сделали в свете рекомендаций DDD. В этот момент вы можете сказать: «О, если бы я сделал , что Сервисом, Модель была бы намного чище», или как угодно.

Может оказаться полезным прочитать пример . :

...