Действительно ли это DDD?

Question

Я на 80% уверен, что мне не следует задавать этот вопрос, потому что это может показаться отрицательным, и я имею в виду отсутствие неуважения к кому-либо, особенно к автору этой книги. Я видел несколько сообщений, рекомендующих это book и его компаньона 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?

Answer 1

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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