ORM으로 DDD 비즈니스 로직은 어디로 가야합니까?

나는 과거에 UML을 통해 모델링 한 MDA (모델 기반 아키텍처) 도구를 사용해 왔으며 이는 비즈니스 항목 (도메인 모델)과 ORM (매핑 등)을 생성했습니다.

도메인에서 작업하는 많은 비즈니스 코드와 서비스는 모델의 일부였으며 우리 저장소는 비즈니스 항목을 반환하고 있었기 때문에 다른 ORM으로 전환 할 수 없었습니다 (원하는 것이 아님).

그러나 이제 프로젝트를 시작하고 있으며 DDD 측면에서 생각하고 싶습니다.

지금까지는 비즈니스 로직을 도메인 모델과 리포지토리를 통해 ORM (내가 선택한 것)과 함께 사용하는 것처럼 느껴집니다. 그러나 응용 프로그램의 ORM 부분에 MDA 도구를 계속 사용하려면 여기에서 만든 모델이 매우 빈약합니다 (즉, 비즈니스 논리를 포함하지 않음). 마찬가지로 ORM에 엔티티 프레임 워크 (.net) 또는 NHibernate를 사용하면 빈혈 모델이 될 것입니다. NHibernate를 방금 사용한 경우 비즈니스 로직을 어디에 배치할지 확실하지 않습니다.

나는 DDD를 사용하여 도메인의 모든 비즈니스 논리를 생각하고 저장소를 통한 지속성을 위해 ORM을 사용한다고 생각합니까?

다른 ORM으로 전환하는 것은 불가능했을 것입니다.

그건 잘못된 것 같습니다. 저장소 패턴의 주요 장점은 데이터 액세스 로직을 숨기고 쉽게 교환 할 수 있다는 것입니다.

지금까지는 비즈니스 로직을 도메인 모델과 리포지토리를 통해 ORM (내가 선택한 것)과 함께 사용하는 것처럼 느껴집니다. 그러나 응용 프로그램의 ORM 부분에 MDA 도구를 계속 사용하려면 여기에서 만든 모델이 매우 빈약합니다 (즉, 비즈니스 논리를 포함하지 않음). 마찬가지로 ORM에 엔티티 프레임 워크 (.net) 또는 NHibernate를 사용하면 빈혈 모델이 될 것입니다. NHibernate를 방금 사용한 경우 비즈니스 로직을 어디에 배치할지 확실하지 않습니다.

빈혈 도메인 모델은 Martin Fowler와 같은 많은 사람들에게 나쁜 습관으로 간주됩니다. 그러한 모델은 좋은 객체 지향 디자인이 아닌 절차 적 디자인 기법으로 이어지기 때문에 그러한 디자인을 피해야합니다. 그런 다음 데이터 클래스와 관리자 / 프로세싱 클래스가 있으므로 상태와 동작이 분리됩니다. 그러나 객체는 실제로 "상태 와 행동" 이어야합니다 .

NHibernate는 영속 무지에서 훌륭한 일을합니다. XML 또는 FluentNHibernate를 사용하여 매핑 세부 정보를 숨기고 일반 POCO를 작성할 수 있습니다. NHibernate로 풍부한 도메인 모델을 생성하는 것은 매우 쉽습니다. 엔티티 프레임 워크와 MDA 도구로도 그렇게 할 수 있다고 생각합니다. 이 도구가 부분 클래스를 생성하는 한, 새로운 세대가 사용자 작성 코드를 파괴 할 염려없이 생성 된 코드를 매우 쉽게 확장 할 수 있습니다.

이 긴 이야기를 짧게 줄이려면 NHibernate를 사용하면 아무것도 반복 하지 않으며 풍부한 도메인 모델을 수용 하지 못하게됩니다. FluentNHibernate와 함께 사용하고 수동으로 매핑하는 것이 좋습니다. 매핑 코드를 작성하는 데 5 ~ 10 분 밖에 걸리지 않습니다. 엔터티 프레임 워크의 경우에도 마찬가지이며 툴은 최소한 쉽게 확장 가능한 부분 클래스를 생성한다고 가정합니다.

나는 DDD를 사용하여 도메인의 모든 비즈니스 논리를 생각하고 저장소를 통한 지속성을 위해 ORM을 사용한다고 생각합니까?

대부분 당신이 맞습니다. 풍부한 도메인 모델이 있어야합니다. 특히 일이 점점 복잡해지면 제대로 설계했을 때 유지 관리 및 확장이 쉬워집니다. 그러나 DDD는 작성 로직을 캡슐화하기 위해 비즈니스 로직 및 팩토리를 구현하는 서비스 (도메인 레이어 및 애플리케이션 레이어)도 알고 있습니다.

또한 비즈니스 로직을 도메인 로직과 실제 애플리케이션 비즈니스 로직으로 차별화하는 경향이 있습니다. 도메인 로직은 도메인이 상호 작용하고 작동하는 방식이며 완전히 다른 계층 인 애플리케이션 로직은 도메인이 특정 사용 사례 / 애플리케이션에 사용되는 방식을 캡슐화합니다. 종종 특정 사용 사례를 지원하고 더 강력하게 만들기 위해 도메인 모델을 업데이트해야합니다.

그러나 응용 프로그램의 ORM 부분에 MDA 도구를 계속 사용하려면 여기에서 만든 모델이 매우 빈약합니다 (즉, 비즈니스 논리를 포함하지 않음).

어떤 MDA 도구를 사용하고 있는지 잘 모르겠지만, 내가 사용한 MDA 도구는 항상 부분 클래스를 생성하므로 원하는만큼 많은 비즈니스 로직으로 자유롭게 완성 할 수 있습니다.

그러나 MDA 도구는 ORM보다 DDD 컨텍스트에서 약간 덜 적합하다고 생각합니다. 코드 생성은 종종 우리가 기대하는 간소화되고 명확하게 표현 된 도메인 엔티티 대신 도구 별 노이즈로 혼동되는 클래스를 생성하는 경향이 있기 때문입니다. 실제로 자주 얻는 것은 도메인 데이터, 지속성 논리, 제약 조건 유효성 검사 논리의 혼합입니다. 이러한 우려를 대부분의 MDA 도구와 분리 할 수있는 방법이 있는지 모르겠습니다.

물론 부분 클래스를 통해서만 생성 된 코드를 만질 수는 없습니다. 이는 통합 될 잠재적 인 안티 -DDD 동작을 제거 할 수 없음을 의미합니다. 이는 집계간에 엄격한 장벽을 적용하고 엔터티 간의 관계를 완벽하게 조정하려는 접근 방식에서 문제가됩니다. 지속적인 통합 환경에서의 빌드 시간은 추가 코드 생성 단계로 인해 어려움을 겪을 수 있습니다.

그 외에도, Falcon은 ORM 또는 MDA 도구에서 풍부한 도메인 엔터티를 갖는 것을 막을 수있는 것은 아무것도 없다고 생각합니다.

내가 팀에서하는 일은 객체, 도메인을 모델링하고 동시에 비즈니스 로직을 추가하는 것입니다. 모델에서 코드를 생성하지만 주석 방식을 선호하는 모델 중심 개발을 사용하지 않습니다. 클래스 다이어그램 내부의 객체 수준에서 ORM 스테레오 타입을 추가한다는 의미입니다. 그러면 EJB3 / hibernate와 호환되는 코드에 직접 지속성 주석이 추가됩니다. 데이터베이스 작성은 UML 템플리트가 아니라 Hibernate에 의해 수행됩니다. 코드가 변경되고 추가 된 주석이 최대 절전 모드 전문가가 아닌 경우이를 변경할 수 있지만 모델은 여전히 ​​우수하기 때문에 이것은 훨씬 더 좋습니다. 또한 요구 사항을 변경할 수 있으며 도메인 모델은 여전히 ​​정상입니다.

개발자는 각 방법 내에 비즈니스 로직을 추가하고 의견을 추가 할 수 있으며 제약 조건을 모델링하고 추가 할 수도 있습니다. 예를 들어 판매가 50k를 넘지 않아야합니다. 코드를 작성할 필요는 없지만 모델을 작성하면 개발자 팀이이 정보를 볼 수 있습니다. 정말 시원하고 유연한 UML.