2011-10-26 2 views
0

좋은 코드를 작성하는 방법의 예로서 사용하기 위해 작성한 코드에 DDD와 유사한 패턴을 적용하려고합니다. 우리는 이미 도메인 객체를 나타내는 많은 클래스를 가지고 있지만 대부분은 "너무 많이 알고 있습니다", 로직, getter/setter 및 데이터 액세스 (타입이 지정되지 않은 DataSet의 형태로)가 모두 존재합니다.DDD와 같은 스타일을 따르는 경우 기존의 "엔터티"를 약간 다른 속성으로 복제해도 괜찮습니까?

응용 프로그램의이 부분에 대해 동일한 도메인 객체를 사용해야하지만 "뚱뚱한"객체를 사용하기가 쉽지 않은 반환 된 데이터의 작은 하위 집합이 필요합니다 (예 : "뚱뚱한"객체가 있다고 가정 해 봅시다). 20 개의 속성과 메서드가 있으며이 부분에 대해서는 7 개의 속성 만 사용하도록주의를 기울였습니다). 필자가 필요로하는 속성만을 사용하여 같은 이름 (다른 네임 스페이스/패키지에 있음)로 기울여 진 DTO 스타일의 객체를 만들 수 있습니까? 나는 이것이 DDD 세계에서 좋은 습관 이었다는 것을 기억하는 것 같다. 그러나 나는 확실히 기억할 수 없다. (내가 기억하는 바운드 문맥과 관련이있다?) 나는 나의 디자인을 오염시키는 것을 싫어할 것이다.

답변

2

저는 여러분이 달성하려고 시도하는 것이 무엇인지 여기에서주의해야합니다. 도메인 중심으로 작동하려면 엔티티가 풍부해야하며 기능이 풍부해야합니다. "anemic" domain model

"동일한 도메인 객체를 사용해야하지만 속성의 하위 집합과 함께 사용해야하는 경우" 이 시나리오에서 정확히 도메인 객체를 사용하고있는 것은 무엇입니까?

실제로 DTO로 사용되고 있으며 실제 기능을 포함하는 다른 관리자 클래스로 전달되고 있습니까?

그렇다면 진정한 도메인 중심인지 확인하기 위해 디자인을 다시 방문하고 싶을 수 있습니다.

관련 문제