도메인 구동 디자인 접근법 (here과 비슷한)을 구현할 생각이지만 Doctrine ORM과 통합하려고합니다. 이런 식으로 성공한 사람이 있습니까?Doctrine을 도메인 기반 디자인과 함께 사용하기
필자의 본능은 Doctrine을 DAO 레이어로 사용했지만 Doctrine이 데이터베이스 필드를 매핑하는 데 다소 복잡한 것처럼 보였고 내 엔터티 개체는 Doctrine 개체의 동일한 필드 집합 (기본적으로)에 매핑됩니다.
내 원래의 목표는 내 도메인 엔티티에서 내 DQL/쿼리 로직을 모두 분리하는 것이었지만 지금은 현재 디자인 패턴의 땅에서 조금 벗어났습니다.
나는 Doctrine 2가 DDD 기법에 훨씬 더 친근한 접근법을 제공해야한다고 알고 있지만, 그렇게 오래 기다리고 싶지는 않다. 내가하고 싶은 것이 의미가 있습니까, 아니면 다른 접근법을 찾아야합니까?
감사합니다.
Doctrine은 Repository 클래스가 없기 때문에 DDD에서 불완전합니다. Doctrine은 Table Data Gateway 및 Active Record와 같은 패턴을 지원합니다. 특정 문제에 대한 좋은 패턴이 반드시 '클래식'DDD를위한 최상의 선택이되는 것은 아닙니다. 그러나 이러한 결함을 해결할 수 있습니다.
하나의 옵션은 Doctrine_Table에서 파생되어 가난한 사람의 저장소로 사용하는 것입니다. 예를 들어 'BlogPost'라는 클래스가있는 경우 Doctrine_Table을 상속받은 'BlogPostTable'테이블 클래스가있을 수 있습니다. 그런 다음 'findByCategory'와 같은 메소드를 BlogPostTable 클래스에 추가하여 이러한 논리를 도메인 객체 (Doctrine_Record에서 상속)와 분리하여 유지할 수 있습니다. 그것은 '순수한'DDD가 주장하는 패턴과 정확히 같지 않지만 충분히 가깝습니다.
정확히 동일한 디자인 패턴이 없어도 DDD의 중앙 통찰력을 사용할 수 있습니다. 주요 유비쿼터스 언어는 도메인 전문가와 개발자가 읽을 수있는 정확한 언어를 사용하여 도메인을 설명하려는 개념입니다.
감사합니다. 나는이 반응이 내 경험을 완전히 반영한 것이라고 생각한다. 교리의 사각형 쐐기는 DDD의 둥근 구멍에 정확히 들어 맞지 않는 것 같습니다. 내 Doctrine_Record 클래스를 My Entities로 취급하고 Doctrine_Table을 DAO 레이어로 사용하여 기본 Repository 클래스를 구현했습니다. 그것이 내가 원하는 분리를 제공하는 반면, 저장소가 때때로 중복되는 것처럼 느껴지기 때문에 다소 서툴거나 구조가 복잡하다고 느낍니다. –
Doomsrine2는 Data Mapper 패턴을 구현하고 Entities는 POPO이므로 DDD에 완벽하게 적합하고 SRP를 아름답게 고수함으로써 Google에서이 답변에 대해 생각해봤을 때 이것이 이제 구식임을 알았습니다. –