불변 개체와 DDD가 함께 사용됩니까?

DDD를 사용하는 시스템 (ORM을 사용하는 모든 시스템)을 고려하십시오. 거의 모든 사용 사례에서 현실적으로 모든 시스템의 요점은 해당 도메인 객체를 조작하는 것입니다. 그렇지 않으면 실제 효과 나 목적이 없습니다.

변경 불가능한 객체를 수정하면 객체가 지속 된 후 새 레코드를 생성하여 데이터 소스에 큰 팽창을 일으 킵니다 (수정 후 이전 레코드를 삭제하지 않는 한).

불변 객체를 사용하면 얻을 수있는 이점을 볼 수 있지만 이런 의미에서 불변 객체를 사용하는 데 유용한 사례를 볼 수는 없습니다. 이것이 잘못 되었습니까?

함수형 프로그래밍에서와 같이 변경 불가능한 객체를 사용한 계산이 반드시 생성 된 모든 객체를 유지하는 것은 아닙니다!

도메인에서 불변이 데이터베이스에서 불변이어야 함을 의미합니까? 예를 들어 고객에게 항상 하나의 주소가 있다고 가정하면 다음을 고려하십시오.

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

이제 고객 ID가 1임을 고려하여 다음 SQL이 실행됩니다.

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 문의 오버 헤드를 피할 수 있습니다. 또한 일부 RDBMS에는 INSERT REPLACE 또는 무언가가 있다고 생각합니다. MySql에는 REPLACE가 있습니다.

DDD에서 불변의 객체는 값 객체와 거의 같습니다. 이 객체들은 엔티티가 아니며, 정체성이 없습니다. 따라서 나는 항상 값 객체를 포함 된 엔티티의 열로 유지합니다 (N / Hibernate를 사용하면 구성 요소를 사용할 수 있습니다). 그들은 자신의 테이블이 없습니다.

변경 불가능한 오브젝트가 데이터베이스에서 맵핑되는 방법에 따라 다릅니다. Joda Time 라이브러리의 DateTime과 같은 구성 요소 인 경우 값을 변경하면 삽입이 아닌 업데이트가 발생합니다. 그러나 불변이 테이블에 행을 요구하는 더 복잡한 경우에는 팽창 문제가 있습니다.

나는 그것이 약한 논쟁이지만, 이런 방식으로 감사 추적을 구현할 수 있다고 생각합니다. 인서트를 통해 불변의 모든 변경 사항을 추적 할 수 있습니다. 이 작업을 수행하는 더 좋은 방법이 많이 있습니다.

구성 요소가 아닌 불변 도메인 개체를 갖는 것은 지속성과 약간 일치하지 않는 것 같습니다.

도메인에 따라 다릅니다. DDD는 프로그래밍 패러다임을 객체 지향으로 지정하지 않습니다. 그러나 객체 지향 패러다임은 데이터베이스에 유지되어야하는 일반적인 응용 프로그램에 적합합니다.

DDD는 단순히 소프트웨어가 해결하려고하는 실제 문제를 나타내는 도메인 모델을 중심으로 소프트웨어를 빌드해야한다고 말합니다. 그 문제가 예를 들어 수학적으로 수학적이라면, 기능적 프로그래밍과 불변의 데이터 구조를 사용하여 도메인 계층을 구현하는 것은 많은 의미가 있습니다.

반면에 문제가 일반적인 엔터프라이즈 응용 프로그램에 더 가깝고 모든 도메인 개체에 대해 불변 개체 구조를 사용하는 경우 DDD를 따르지 않는다고 주장합니다. 적어도 두 가지 주장을 할 수 있습니다.

• 구현이 문제 도메인의 도메인 모델을 나타내지 않습니다. 이 경우 문제 도메인은 수정할 상태가있는 엔터티로 구성됩니다. 그리고 그것이 당신이 그것을 구현 한 방법이 아닙니다.

• 유비쿼터스 언어가 없습니다. 도메인 모델의 언어와 개념은 도메인 전문가가 사용하는 것을 따르지 않습니다.

참고 : DDD는 적절한 경우 불변 개체를 사용하며,이를 단순히 값 개체라고합니다.

따라서 순전히 기능적인 데이터 구조를 사용하여 데이터베이스 응용 프로그램을 만들 수 없다는 말은 아니며,해서는 안된다는 말은 아닙니다. 응용 프로그램의 유형에 따라 DDD라고 부를 수 없다고 생각합니다.

Hibernate / NHibernate와 같은 ORM을 사용하는 경우 고아 개체를 자동으로 삭제하도록 계단식 옵션을 설정할 수 있습니다. 개인에게 값 개체 주소가있는 경우, 주소를 변경하면 새 주소가 저장되고 기존 주소가 분리되어 이전 주소가 삭제됩니다.

값 객체는 거의 항상 DDD에서 변경할 수 없으며 플라이급 패턴을 사용하여 .NET이 문자열을 사용하는 것처럼 메모리에서 해당 값 객체의 복제를 유지합니다. 주요 트레이드 오프는 한면의 메모리이고 다른면은 창조 효율성입니다. 플라이급 패턴을 사용하면 새로운 또는 재구성 된 값 객체가 이미 플라이급 캐시 내에 있는지 여부를 판별하기 위해 값 기반 비교를 수행해야하지만, 단일 인스턴스가 시행되므로 해당 지점 이후의 다른 비교는 일반적으로 참조로 안전하게 수행 할 수 있습니다. 플라이 웨이트 사용 여부에 관계없이 가치 객체는 고유 한 정체성 만 가지고 있으므로 값을 변경하면 정체성이 변경되기 때문에 여전히 불변입니다.

불변 개체를 사용하는 또 다른 방법이 있습니다 ...

5.0, 6.0, 7.0, 8.0 값을 저장하고 매번 전체 레코드를 복사하는 대신 5.0, +1.0, +1.0, +1.0과 같은 것을 저장 한 다음 시퀀스 5.0을 재구성하기 위해 종속성을 올바르게 빌드 할 수 있습니다. , 6.0, 7.0, 8.0. 이런 식으로 작은 수정은 적은 양의 메모리 만 필요합니다 ...