Это действительно DDD?

Я на 80% уверен, что мне не следует задавать этот вопрос, потому что это может показаться отрицательным, и я имею в виду отсутствие неуважения к кому-либо, особенно к автору этой книги. Я видел несколько сообщений, рекомендующих эту книгу и ее компаньон project. Я не читал книгу, но сегодня я провел несколько часов, изучая этот проект. И хотя это выглядит очень полно, мне очень трудно разобраться, насколько детали разных вещей разбросаны. Я борюсь в своих собственных проектах, сколько я должен изменить, если сущность меняется, и этот проект не делает меня очень удобным в качестве решения.

Например, существует объект Employee, который наследуется от Лица. У человека есть конструктор с именем, фамилией и т.д., И, следовательно, Employee. Private to Employee - это члены для имени, фамилии, а также для общедоступных объектов.

Существует EmployeeFactory, который знает о свойствах Employee и Person, а также имена столбцов SQL (чтобы вытащить значения из считывателя).

Существует EmployeeRepository с нереализованными методами PersistNewItem и PersistUpdatedItem, которые, как я подозреваю, если они будут реализованы, будут строить SQL для операторов INSERT и UPDATE, как я вижу в CompanyRepository. Они записывают свойства в строки для построения SQL.

Существует "Контракт данных" PersonContract с теми же частными членами и общедоступными свойствами, что и Person, и EmployeeContract, который наследует от PersonContract, как Employee does Person, с общедоступными свойствами, отражающими объекты.

Существует статический класс "Конвертер" со статическими методами, которые отображают объекты в Контракты, включая

EmployeeContract ToEmployeeContract(Employee employee)

который копирует поля от одного к другому, включая поля Person. Может быть сопутствующий метод, который идет в другую сторону - не уверен.

Я думаю, что есть и юнит-тесты.

Во всех случаях я подсчитываю 5-10 классов, методов и конструкторов с подробными сведениями об объектных свойствах. Возможно, они автогенерированы - не уверен. Если мне нужно было добавить "Приветствие" или другое свойство Лицу, мне пришлось бы корректировать все эти классы/методы? Я уверен, что что-то забуду.

Опять же, я имею в виду отсутствие неуважения, и это, кажется, очень подробный, подробный пример для книги. Это как DDD?

Ответ 1

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

В любом случае короткий ответ (IMAO) - "да, но...". Идея создания управляемого доменом дизайна заключается в том, чтобы моделировать домен очень четко. То, что вы ищете, является моделью домена, то есть объектно-ориентированной моделью, которая описывает проблемную область на языке проблемной области. Идея заключается в том, что модель домена, поскольку она моделирует "реальный мир", относительно нечувствительна к изменениям, а также стремится локализовать изменения. Итак, если, например, ваша идея о том, что представляет собой Работник, возможно, добавив почтовый адрес, а также физический адрес, эти изменения будут относительно локализованы.

Как только у вас есть эта модель, у вас есть то, что я поддерживаю, архитектурные решения еще предстоит сделать. Например, у вас есть невыполненный уровень персистентности, который действительно может быть просто построением SQL. Это также может быть слой Hibernate или использовать травление Python или даже быть чем-то диким, как структура распределенной таблицы Google AppEngine.

Дело в том, что эти решения принимаются отдельно и с другими соображениями, чем решения моделирования домена.

То, что я экспериментировал с каким-то хорошим результатом, - это сделать модель домена на Python, а затем создать имитатор с ним вместо внедрения конечной системы. Это делает что-то, что может экспериментировать с клиентом, а также потенциально позволяет делать количественные оценки о том, что должна определить конечная реализация.

Ответ 2

Домен Driven Design действительно прост. В нем говорится: сделайте классы модели зеркальными в реальном мире. Поэтому, если у вас есть Сотрудники, у вас есть класс Employee и убедитесь, что он содержит свойства, которые дают ему "Employee-ness".

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

Ответ 3

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

это значительно улучшает код; альтернативой является репозиторий для каждого модельного класса, который является "просто" многоуровневым дизайном, а не DDD