Неизменные объекты и DDD идут вместе?

Рассмотрим систему, которая использует DDD (также: любую систему, которая использует ORM). Смысл любой системы реалистично, почти в каждом случае использования, состоит в том, чтобы манипулировать этими объектами домена. В противном случае нет никакого реального эффекта или цели.

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

Я вижу выгоду от использования неизменяемых объектов, но в этом смысле я никогда не вижу полезного случая использования неизменяемых объектов. Это неправильно?

Вычисления с использованием неизменяемых объектов (как в функциональном программировании) не обязательно подразумевают сохранение каждого сгенерированного объекта!

Означает ли неизменяемость в домене, что она должна быть неизменной в базе данных? Например, рассмотрим следующее, предполагая, что клиент всегда имеет один адрес:

customer.address = new Address('My Castle', 'Kings street');
customer_repo.save(customer);

теперь запускается следующий sql, учитывая, что идентификатор клиента равен 1:

INSERT INTO addresses (customer_id, name, street)
VALUES (1, 'My Castle', 'Kings street');

Теперь в адрес внесены следующие изменения:

customer.address = new Address('Pauper palace', 'Outlands');
customer_repo.save(customer);

и уровень персистентности, будучи очень умным, запускает следующий sql:

UPDATE addresses SET name='Pauper palance', street='Outlands'
WHERE customer_id = 1;

Таким образом вы избежите накладных расходов на отдельную инструкцию DELETE AND INSERT. Также я думаю, что некоторые РСУБД имеют ЗАМЕНУ ВСТАВКИ или что-то в этом роде. MySql имеет ЗАМЕНУ .

В DDD неизменяемые объекты в значительной степени приравниваются к объектам-значениям. Эти объекты не являются сущностями, у них нет идентичности. Поэтому я всегда сохраняю объекты-значения как столбцы сущности, в которой они содержатся (для N / Hibernate вы можете использовать компоненты для этого). У них нет собственного стола.

Это зависит от того, как неизменяемый объект отображается в базе данных. Если это просто компонент типа DateTime (из библиотеки Joda Time), то изменение значения приведет к обновлению, а не к вставке. Однако, если неизменяемый объект более сложный, требующий строки в таблице, у вас есть проблема с раздуванием.

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

В общем, наличие неизменяемых доменных объектов (а не просто их компонентов) кажется немного несовместимым с постоянством.

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

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

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

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

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

Примечание: DDD использует неизменяемые объекты, где это уместно, они просто называются объектами значений.

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

Если вы используете ORM, например Hibernate / NHibernate, вы можете установить каскадную опцию для автоматического удаления осиротевших объектов. Если у человека есть объект значения «Адрес», при изменении адреса новый будет сохранен, а старый удален, поскольку теперь он потерян.

Объекты значений почти всегда неизменны в DDD, и шаблон flyweight можно использовать для сохранения дублирования этого объекта значений в памяти, как это делает .NET со строками. Основным компромиссом является память с одной стороны, а с другой стороны - творческая эффективность. С шаблоном flyweight, сравнение на основе значений должно быть выполнено, чтобы определить, находится ли какой-либо новый или восстановленный объект значения уже в кэше flyweight, но любое другое сравнение после этой точки, как правило, может быть безопасно выполнено посредством ссылки, так как применяется один экземпляр. В любом случае, независимо от того, используется весовой вес или нет, объекты-значения по-прежнему остаются неизменяемыми, поскольку они имеют только внутреннюю идентичность и, следовательно, изменение их значения может изменить их идентичность.

Есть еще один способ использовать неизменяемые объекты ...

Вместо того, чтобы хранить значения 5.0, 6.0, 7.0, 8.0 и копировать всю запись каждый раз, вы можете вместо этого сохранить что-то вроде этого: 5.0, +1.0, +1.0, +1.0, а затем правильно построить зависимости, чтобы восстановить последовательность 5.0 6,0, 7,0, 8,0. Таким образом, небольшие модификации занимают небольшое количество памяти ...