2013-09-16 2 views
2

나는 현재 ORM을 사용하고 가능한 한 DDD를 고수하면서 기존 응용 프로그램을 재 모델링하려고합니다.Doctrine을 사용하는 DDD

작업 지시는 AR이며 12 개 이상의 하위 엔티티가 있습니다. 이 클래스를 다음과 같이 모델링하려고했습니다 :

class WorkOrder { 

    private $number = 0; 
    private $manual = ''; 

    ... 

    // Sub-Entities 

    private $consumables; // Collection (1:m) 
    private $dimensions; // Collection (1:m) 
    private $sequences; // Collection (1:m) 

    ... 

} 

이제이 집계를로드 할 저장소가 필요합니다.

Repo는 서브 엔티티 (간접 getter/setters를 통해 - 점 표기법을 사용하지 않음)에 액세스 할 때 내가 나중에있는 정보를 게으른로드 할 수있는 하나 이상의 집계를 반환합니다. ???

내가 작업 지시를 만드는 공장 역할을하는 다른 클래스해야합니다

- 상세한 과정 및 실질적인 비즈니스 로직/유효성 검사 규칙을 포함 ...

그러나 공장 만드는 경우 작업 지시 집계가하는

레포는 단지 AR을 유지합니까?

이 팩토리는 (REST 또는 기타를 통해) 타사 서비스를 쿼리해야하며 기본적으로 작업 범위를 설명하는 승인 된 문서의 스냅 샷을 작성해야합니다.

그래서 저장소는 ORM을 캡슐화 했습니까? 아니면 내가 선택한 지속성 계층을 캡슐화합니까?

지금과 같이 보일 것 내 파일 구조 :

createWorkOrderFromRpi() 
createWorkOrderFromCsv() 
... 

I : 같은 방법이있을 것입니다

FindOneByTrackingNumber() 
FindAllByCriteria() 

save($root); 

내 공장 : 저장소 같은 방법이있을 것입니다

WorkOrder/ 
    /Factory.php 
    /Aggregate.php 
    /Repository.php 

    /Entity/Header.php 
    /Entity/Shipping.php 
    /Entity/Warranty.php 
    /Entity/Certification.php 
    ... 

을 여기에 여러 기사와 수많은 게시물을 읽었습니다.

http://williamdurand.fr/2013/08/07/ddd-with-symfony2-folder-structure-and-code-first/

디테일이 우수하지만나는 내 자신의 해석에 관한 두 번째 의견을하시기 바랍니다해야합니다. :)

안부, 알렉스

+0

나는이 점에 관해서 여기에서 집으로 돌아 간다. -> http://stackoverflow.com/questions/13894200/making-a-fat-model-in-symfony-2-composition-or-inheritance-and-how- to-configur 이제 DDD를 사용하여 SF2 애플리케이션을 다시 구현하기 시작했습니다. 위 링크를 이용해 주셔서 감사합니다! – calumbrodie

답변

5

교리는 DDD에 적합하지 않습니다. 그것은 깊은 도메인 개체 관계를 처리 할 수 ​​없습니다. 나는 주석을 많이 작성하거나 메타 데이터를 매핑하지 않고 실제로 객체를 잘 매핑하는 ORM 영역이 없다고 생각합니다. ORM은 도메인 모델을 올바르게 구축하면 쓸모가 없습니다.

DDD의 기본 규칙 중 하나 인 집계 당 하나의 트랜잭션을 고려해야합니다. 이 규칙을 염두에두고 도메인 모델을 설계하면 지속성에도 도움이됩니다. 더 이상 관계형 데이터베이스가 필요 없다는 것을 알게됩니다. RDBMS를 사용하더라도 확장성에 도움이됩니다.

예 도메인 개체를 유지하는 데 99 %의 사례가있는 저장소가 사용됩니다. 리포지토리는 도메인 개체가 신경 쓰지 않아야하는 데이터로 반사를 사용하여 자동으로 도메인 개체를 채울 ORM이 아닌 매핑을 처리해야합니다.

리포지토리에서 고유 한 매핑 (간단한 속성 db 테이블 열 매핑)을 만드는 것은 집계를 제거하고 저장할 때 어렵지 않습니다. 문제는 집계를 업데이트하는 것이지만 문제는 매핑이 아니라 도메인 개체의 상태 변경 내용을 추적하는 것입니다. 그러나 이것은 다시 매핑 문제가 아니라 작업 단위의 문제입니다.

이제이 집계를로드 할 저장소가 필요하겠습니까?
수정하십시오. 저장소는 도메인 상태 변경 사항을 유지하고 도메인의 상태를 다시 구성합니다.

Repo는 서브 엔티티 (간접 getter/setters를 통해 - 점 표기법을 사용하지 않음)에 액세스 할 때 지연된 정보를 나중에로드 할 하나 이상의 집계를 반환합니다 ???
예 (도메인 모델을 사용하여 도메인을 채우는 경우 도메인 모델을 사용하여 도메인의 상태를 계속 추적 할 수있는 cqrs에 위치 함). 당신은 setter를 가질 필요가 없습니다. 상태를 변경하는 메소드 만 있으면됩니다.이 메소드는 유비쿼터스 언어 (changeName, addItemToCart)를 반영합니다. 게으른 로딩은 메모리를 절약하는 데 유용합니다. 메모리가 문제가 아닐 경우 도메인 객체의 스냅 샷을 최신 상태로 만들 수도 있습니다. 네, 게으른 로딩은 도메인 객체에 게터 (getter)를 갖도록 강요하는 ORM의 작업입니다. 이는 DDD의 큰 한계입니다.

그러나 공장에서 작업 주문 집합을 생성하면 repo가 ​​AR을 그대로 유지합니까?
팩토리가 도메인에 새 상태를 만듭니다. 저장소는 한 번 공장에서 생성 된 상태를 재구성합니다.

그래서 저장소는 ORM을 캡슐화 했습니까? 아니면 내가 선택한 지속성 계층을 캡슐화합니까?
예 저장소가 도메인 상태의 재구성을 처리해야합니다. ORM은 기술적 인 문제 일 뿐이며 단지 라이브러리 일뿐입니다. 어쨌든 ORM은 공통 라이브러리/공유 커널 계층의 일부이고 저장소는 인프라 계층의 일부입니다.

파일 구조와 관련하여 DIP, IOC, DDD 경계 컨텍스트에 대해 자세히 읽어야합니다. 이렇게하면 구성 요소를 기반으로 응용 프로그램을 빌드하는 데 도움이되며 구성 요소를 확장 가능한 응용 프로그램으로 분리 할 수 ​​있습니다.

+0

이것은 정확히 DDD와 ORM에 대한 생각입니다. 나는 아직 내 생각을 확인하는 사람의 답을 찾지 못했습니다. 나는 조금 걱정하고 있었다. 그러나이 대답은 계속되었다. 고맙습니다. – prograhammer

+0

나는 ORM없이 변경 사항 추적에 더 관심이 있습니다. 또는 업데이트 및 삭제 부분 만 해결할 수도 있습니다. 당신이 어떻게하는지 공유 할 수 있습니까? –

관련 문제