DDD:как должны быть организованы слои?
Я очень новичок в разработке программного обеспечения. Лично я считаю, что многоуровневая архитектура-это отличный способ уменьшить сложности, возникающие в процессе разработки программного обеспечения в объектно-ориентированном подходе и, не говоря уже, сохранить организованность кода. Теперь я столкнулся с некоторыми проблемами, которые будут представлены с DDD (Domain Driven Design). Конечно, начинающие.
Вот это –
Предположим, я хочу создать приложение для сохранения связанных с" человеком " данных в базе данных и отображение сведений о человеке в WPF datagrid (DDD определенно не для приложений такого масштаба, но просто для того, чтобы все было просто для любителя, как я). Итак, я разработал доменный класс "Person", что – то вроде -
public class Person
{
public Person(dataType paramA, dataType paramB)
{
_fieldA = paramA;
_fieldB = paramB;
}
private dataType _fieldA;
public dataType PropertyA
{
//encapsulates _fieldA
}
private dataType _fieldB;
public dataType PropertyB
{
//encapsulates _fieldB
}
public dataType PropertyX
{
//some code based on private fields
}
public dataType PropertyY
{
//some code based on private fields
}
private dataType MethodPQR(dataType param)
{
//some code
}
public dataType MethodUVW(dataType paramOne, dataType paramTwo)
{
//some code
}
}
теперь, мое понимание DDD говорит, что архитектура (самая простая версия) должна быть следующей (пожалуйста, поправьте меня, если я ошибаюсь) -
Примечание:
Я хочу, чтобы datagrid был привязан к некоторой ObservableCollection, просто чтобы мгновенно отразить любые изменения.
Это приложение wpf, но не обязательно должно быть в шаблоне MVVM, и я намеренно хочу использовать код позади (я понятия не имею, представляет ли код позади себя уровень приложения)
Итак, мои вопросы –
какие коды должны принадлежать прикладному уровню?
мое предположение, я определенно не должен связывать ObservableColletion моего объекта домена (Person) в качестве itmsSource datagrid. Какой тип объекта я должен извлечь из объекта домена и как?
чтобы сохранить развязку между объектами слоя представления и объектом слоя домена, может быть соглашение, такое как
“never instantiate domain objects directly in presentation layer”. Каковы же тогда не "прямые" подходы?Если код-за переговорами со слоем приложения, то должен ли слой приложения говорить с Хранилище? Но что, если необходим какой-то доступ к домену, который не доступ к данным, связанным (может быть, не в этом приложении, но это может произойти, не так ли?) Кто этот парень X в доменном слое, с которым должен разговаривать слой приложений?
Я знаю, что все мои вопросы и проблемы на очень любительском уровне. Но это действительно вопросы и проблемы. Поэтому, если у кого-то есть время, любой ответ будет оценен.
EDIT: я не конечно, если хранилище данных должно иметь ссылку на модель домена.
1 ответов
говоря с точки зрения более "классического" DDD, да, объекты домена обычно не допускаются нигде за пределами домена. Но это не абсолютное правило, что объекты домена не используются в слое представления. Например, голые объекты представляют собой школу мысли, где объекты домена используются непосредственно. Я сам придерживаюсь в основном философии, где объекты домена не используются напрямую, поэтому я не знаком со всеми практиками, которые они предлагают, я лично считаю обязательными к объекту домена напрямую было бы нецелесообразно, но ... Просто имейте в виду, что не все рассматривают это как требование.
Если вы не разрешаете объекты домена вне самого домена, вы обычно используете DTO или объекты передачи данных, которые являются простыми классами свойств, которые не имеют поведения домена. DTOs часто точно отражают структуру модели домена, но не обязательно.
бизнес-логика должна быть реализована в модели предметной области, так то, что находится на уровне приложения, связано с координацией различных служб, как правило, для передачи данных клиентским приложениям и из них. Многие люди используют для этого какую-то форму SOA или, по крайней мере, веб-сервисы. Они вызывают репозитории, но также требуют, чтобы другие компоненты, такие как ассемблеры, принимали объекты домена, возвращенные из вызовов репозитория, и копировали значения свойств в DTOs, которые затем сериализуются и возвращаются вызывающему объекту. Вызывающий часто является ведущим или контроллер, но если вы не используете MVC или MVP, вызывающий объект все равно будет на уровне презентации. Обратная поездка более сложна-пользовательский интерфейс может отправлять обратно DTOs, которые представляют обновления или DTOs, которые представляют новые объекты для добавления. Опосредование этих взад и вперед действий в первую очередь является целью прикладного уровня.
Что касается" доступа без данных " уровня домена, есть несколько типичных примеров. Большинство людей обычно ссылаются на компонент "X", которым вы можете быть думая о качестве доменной службы. Доменная служба отличается от службы приложений близостью к модели домена и наличием фактической бизнес-логики.
например, если приложение включает в себя какое - то размещение заказа, на самом деле есть две проблемы-размещение заказа и выполнение заказа. Службы приложений опосредуют передачу данных, необходимых для формулирования размещения заказа в пользовательский интерфейс, а затем возвращают заказ, который пользователь хочет разместить. Но это только посредничество передачи данных, и именно там заканчиваются службы приложений. Затем может потребоваться доменная служба для применения бизнес-правил и создания дополнительных объектов домена, необходимых для выполнения этого заказа.
В общем, я считаю, что это полезная концепция или метафора, которая может быть применена ко многим сценариям - служба приложений облегчает какой-то запрос, с точки зрения запроса представления только . Доменная служба с другой стороны рука облегчает фактический запрос исполнение.
единственный другой режим "доступа", кроме ориентированного на данные, с которым я столкнулся или могу легко представить, - это функциональность, ориентированная на процесс. Это не встречается в каждом приложении, но распространено в некоторых областях. Например, в здравоохранении, где я работаю, вам могут понадобиться приложения, включающие важные элементы управления как клиническими данными, так и клиническим процессом. Я решаю эту проблему, не делая акцент на этом процессе частью моей модели домена и используя для этого различные инструменты.
методы ООП не хорошо подходят для самого процесса, они полезны для предоставления данных и сбора данных из процесса. Объектно-ориентированный, в конце концов, также в первую очередь ориентирован на существительное. Для управления процессами в реальном времени вам нужно "глагольное ориентированное программирование "больше, чем"существительное ориентированное программирование". Инструменты рабочего процесса-это инструменты," ориентированные на глаголы", которые могут дополнять друг друга к доменным моделям для приложений, которые являются интенсивными как для данных, так и для процессов. Я делаю много работы, которая включает в себя как модели C# DDD, так и модели Workflow Foundation, но опять же это необходимо только для определенных типов приложений. Для многих типичных бизнес-приложений требуются только доменные модели и службы.
наконец, самый важный аспект DDD-это не какая-либо техника или архитектура. Настоящая суть ее вращается вокруг вездесущего языка и взаимодействие с (на мой взгляд, прямое взаимодействие с) экспертами домена для выделения критических знаний в области. (Большинство компаний, которые утверждают, что делают DDD, на мой взгляд, не потому, что так много компаний отказываются позволить бизнесу и развитию напрямую взаимодействовать, но это другая тема... ) Это извлечение и включение знаний о домене, а не какой-либо метод, который фактически отделяет DDD от обычного ООП, и именно здесь реальная ценность DDD возникает.
редактировать
Что касается использования репозитория, диаграмма верна. Обычно уровень приложения всегда проходит через репозиторий для объектов домена. Прежде всего, вы должны иметь возможность приносить данные в приложение, и большинство приложений также нуждаются в некотором уровне запросов.
уровень домена OTOH обычно делает не взаимодействие с репозиториями. Обычно вы хотите, чтобы модель домена была самодостаточной и отделенный от любой конкретной технологии, я.e он должен представлять собой "чистое знание домена". Настойчивость по своей сути тесно связана с какой-то конкретной технологией, поэтому в целом люди стремятся сделать свои модели домена свободными от любой реализации настойчивости. У вас есть репозитории, но вы обычно не хотите вызывать методы репозитория в модели домена.
внутри самой модели домена объекты получаются либо как новые объекты (которые могут быть созданы непосредственно или через фабрику) или же достигаются путем прохождения ассоциаций. Иногда при создании нового объекта нецелесообразно передавать все необходимое в конструктор, поэтому это один из случаев, когда вам может потребоваться какой-то доступ к данным в самой модели домена. Обычно люди передают службу данных через интерфейс, чтобы модель домена могла иметь доступ к данным, но оставалась отделенной от реализации уровня данных. Но по большей части объекты домена действуют и взаимодействие с другими объектами домена,которые уже созданы.