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

Question

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

Например, есть объект Employee, который наследуется от Person. У Person есть конструктор с именем, фамилией и т. Д. И, следовательно, с Employee. Приватные сотруднику являются члены для имени, фамилии, а также общедоступные свойства для того же.

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

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

Существует PersonContract «Контракта с данными» с теми же частными членами и общими свойствами, что и Person, и EmployeeContract, который наследуется от PersonContract, как Employee с Person, с открытыми свойствами, отражающими сущности.

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

EmployeeContract ToEmployeeContract(Employee employee) 

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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