DDD: как слои должны быть организованы?

Im очень много нового в разработке программного обеспечения. Лично я считаю, что многоуровневая архитектура - отличный способ уменьшить сложности, возникающие в процессе разработки программного обеспечения в объектно-ориентированном подходе, и не говоря уже о том, чтобы сохранить ваш код организованным. Теперь я сталкиваюсь с некоторыми проблемами, которые нужно вводить с помощью DDD (Domain Driven Design). Конечно, начинающие уровни.
Вот он -
Скажем, я хочу создать приложение для сохранения связанных с человеком данных в базе данных и отображения сведений о человеке в wpf datagrid (DDD определенно не для приложений такого масштаба, а просто для того, чтобы все было просто для такой забавной, как я), Итак, я разработал класс домена "Лицо", что-то вроде -

public class Person
 {
    public Class1(dataType fieldAParam)
    {
        _fieldA = fieldAParam;
    }

    private dataType _fieldA;
    public dataType PropertyA
    {
        //encapsulates _fieldA    
    }

    private dataType _fieldB;
    public dataType PropertyB
    {        
        //encapsulates _fieldB    
    }

    private dataType _fieldC;
    public dataType PropertyC
    {        
        //encapsulates _fieldC    
    }

    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 говорит, что архитектура (простейшая версия) должна быть следующей (plz, исправьте меня, если я ошибаюсь) -

Примечание:

Я хочу, чтобы datagrid привязывался к некоторому ObservableCollection, чтобы мгновенно отразить любые изменения.
Это приложение wpf, но не обязательно должно быть в шаблоне MVVM, и я намеренно хочу использовать код позади (я понятия не имею, что сам код представляет собой уровень приложения)

Итак, мои вопросы -

Какие коды должны принадлежать слою приложения?
Я предполагаю, что я определенно не должен привязывать ObservableColletion моего объекта домена (Person) как itmsSource файла datagrid. Какой тип объекта я должен извлечь из объекта домена и как?
Чтобы сохранить развязку между объектами уровня представления и объектом уровня домена, может быть соглашение, подобное "never instantiate domain objects directly in presentation layer". Каковы же не "прямые" подходы?
Если код-Behind разговаривает с уровнем приложения, то должен ли интерфейс приложения разговаривать с репозиторием? Но что, если нужен какой-то доступ к домену, который НЕ связан с доступом к данным (может быть, нет в этом приложении, но это может произойти, правильно)? Whos, что X парень в доменном слое, с которым должен говорить уровень приложения?

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

EDIT: Я не уверен, что в Data Repository должна быть ссылка на модель домена.

Ответ 1

Говоря о более "классическом" DDD, да, объекты домена, как правило, не допускаются нигде вне домена. Но не абсолютное правило заключается в том, что объекты домена не используются в уровне представления. Например, Naked Objects представляет собой школу мысли, где объекты домена используются напрямую. Я сам придерживаюсь в основном философии, в которой объекты домена не используются напрямую, поэтому я не знаком со всеми практиками, которые они предлагают, я лично думаю, что привязка к объекту домена напрямую будет плохой совет, но... Просто имейте в виду не каждый рассматривает это как требование.

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

Предполагается, что бизнес-логика будет реализована в модели домена, поэтому многое из того, что находится на прикладном уровне, связано с координацией различных служб, как правило, для переноса данных в клиентские приложения и из них. Для этого многие люди используют некоторую форму SOA или, по крайней мере, веб-службы. Они вызывают репозитории, но также требуют, чтобы другие компоненты, такие как сборщики, принимали объекты домена, возвращаемые из вызовов репозитория, и копировали значения свойств в DTO, которые затем сериализуются и возвращаются вызывающему. Вызывающий часто является ведущим или контроллером, но если вы не используете MVC или MVP, вызывающий объект все равно будет находиться на уровне презентации. Обратное путешествие более сложное - пользовательский интерфейс может отправлять обратно DTO, представляющие обновления или DTO, которые представляют новые объекты, которые будут добавлены. Посредничество этих операций вперед и назад является в первую очередь целью прикладного уровня.

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

Например, если приложение связано с каким-то порядком размещения, на самом деле есть две проблемы: размещение заказов и выполнение заказов. Службы приложений опосредуют передачу данных, необходимых для формулирования размещения заказа, в пользовательский интерфейс, а затем возвращают заказ, который пользователь хочет разместить. Но это только посредничество в передаче данных, и именно там заканчиваются Application Services. Затем может потребоваться доменная служба для применения бизнес-правил и создания дополнительных объектов домена, необходимых для фактического выполнения этого заказа.

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

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

Методы ООП не очень хорошо подходят для самого реального процесса, они полезны для предоставления данных и сбора данных из процесса. Объектно-ориентированная ведь в первую очередь ориентирована на существительное. Для управления процессом в реальном времени вам нужно "глагольное ориентированное программирование" больше, чем "ориентированное на существительное программирование". Инструменты рабочего процесса являются "ориентированными на глагол" инструментами, которые могут дополнять модели, управляемые доменом, для приложений, которые являются как интенсивными, так и интенсивными процессами. Я выполняю большую работу, которая включает в себя как модели С# DDD, так и модели Workflow Foundation, но опять же это необходимо только для определенных типов приложений. Для многих типичных бизнес-приложений требуются только модели и службы домена.

Наконец, самым важным аспектом DDD является не какой-либо метод или архитектура. Реальное сердце этого вращается вокруг Вездесущего языка и взаимодействия с (в моем сильном мнении DIRECT-взаимодействии с) экспертами по доменам, чтобы отделить критические знания домена. (Большинство компаний, которые утверждают, что делают DDD, по-моему, не потому, что многие компании отказываются напрямую взаимодействовать с бизнесом и развитием, но это еще одна тема...) Это экстракция и включение знаний домена, а не любых метод, который фактически отделяет DDD от обычного ООП, и именно там возникает реальная ценность DDD.

ИЗМЕНИТЬ

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

Уровень домена OTOH обычно не взаимодействует с репозиториями. Как правило, вы хотите, чтобы модель домена была автономной и отделялась от какой-либо конкретной технологии, то есть должна представлять собой "чистое знание домена". Стойкость по своей сути тесно связана с какой-то конкретной технологией, поэтому в целом люди стремятся сделать свои модели домена свободными от реализации настойчивости. У вас есть репозитории, но вы обычно не хотите вызывать методы репозитория в модели домена.

В рамках самой модели домена объекты получаются либо как новые объекты (которые могут быть созданы непосредственно или через factory), либо достигнуты путем обхода ассоциаций. Иногда при создании нового объекта нецелесообразно передавать все необходимое в конструктор, так что это один случай, когда вам может понадобиться какой-то доступ к данным в самой модели домена. Обычно то, что делают люди, проходит через службу данных через интерфейс, так что модель домена может быть обеспечена доступом к данным, но остается изолированной от реализации уровня данных. Но по большей части объекты домена действуют и взаимодействуют с другими объектами домена, которые уже созданы.