도메인-드리븐 디자인 요약의 또하나의 포스트 입니다. DDD를 설명하는 포스트의 번역인데요, 원문에서도 언급하듯이 DDD를 확실히 이해하려면 전반적인 모든 것을 알고 있어야

하고, 알고 있더라도 개인적인 경험에 의존하기 때문에 매우 어렵습니다. 다행이도 전체를 조망하는 통찰력을 가진 글을 읽음으로써 우리는 좀더 쉽게 DDD를 이해할 수 있습니다.

아래에 번역한 포스트가 바로 그런 글입니다.

번역 :

Domain-driven Design
http://powerdream5.wordpress.com/2007/10/15/domain-driven-design/

Domain-Driven Design(DDD)은 제가 존경하는 전문가중의 한명인 Eric Evans(http://domainlanguage.com/)가 변론한 소프트웨어 개발 접근법입니다.  DDD의 주요 목적은 도메인과 도메인 로직에 집중하여 요구사항에서 빗나가지 않게 하는 것입니다.
 
DDD는 유용하다는 것과 전통적인 소프트웨어 개발 방법론의 문제점을 극복할 수 있음을 보여 줍니다. 불행한 점은 DDD를 완전히 이해하는 것은 매우 어렵우며, 여러분의 경험에 매우 의존적이라는 것입니다. 여러분은 또한 실제 프로젝트에 적용하고, 여러분의 경험을 반복해서 집약해야 합니다. 솔직히 말해서 저도 DDD를 조금만 알 뿐입니다. 하지만, DDD에 대한 저의 생각을 나눌것이며 여러분의  댓글을 환영합니다.

Domain-driven design Building Blocks



우리는 도메인 모델에서 그들의 책임을 기준으로 나눌수 있는 5개의 역할을 가지고 있습니다. 5개의 역할은 Enity, Value Object, Factory, Repository 그리고 Services  입니다. 이것들을 저의 지식에 근거하여 설명해 보려 합니다.

       Entity: 엔터티는 사용자와 소프트웨어 개발자 모두에게 관련이 되어 있기 때문에 도메인 모델에서 가장 중요한 부분입니다. 엔터티는 소트프웨어의 상태 변화와 관계없는 아이텐티티를 가지고 있습니다. 다른 말로 하면, 우리는 엔터티를 데이터베이스와 같은 그 어딘가에 저장해야 합니다.

       Value Object: 엔터티는 아이텐티티를 가지고 있고 아이덴티티는 변경될 수 없기 때문에 어플리케이션이 엔터티를 생성하고 추적하는 데에는 비용이 많이 듭니다. 성능을 고려해 보면 도메인 모델의 모든 명사(noun)들을 엔터티로 매핑하는 것은 비합리적 입니다.  Value object 는 아이텐터티가 없으며, 여러분의 도메인 모델의 다른 오브젝트 들이 공유할 수 있는 오브젝트 입니다.

 Domain-Driven Design의 장점을 취하려 할때  엔터티와 value object를 구별하는 것이 우리가 만나는 첫번째 장애물입니다 . 어떤 오브젝트가 아이덴터티를 가져야 할지 말아야 할

지는 전적으로 소프트웨어 개발자가 결정하며, 거기에는 어떤 직접적인 규칙이 없습니다. 저의 의견은 엔터티를 인식하는 일은 오브젝트를 테이블에 매핑하는 것과 유사합니다.

Embedded value 패턴을 기억합니까? 어떤 종류의 오브젝트가 자신의 테이블을 가지고 매핑되어야 하고, 어떤 종류의 오브젝트가 부모 테이블에 매핑되어야 할지? 이 질문에 대한

답은 여러분의 판단 능력과 경험에 달려 있습니다.

         Factory: Factory는 엔터티를 생성할 책임이 있습니다. 일반적으로, 여러분의 도메인 모델에서 엔터티는 항상 다른 오브젝트들과 관계를 가지고 있기 때문에 엔터티를 생성하

는 과정은 복잡합니다. 엔터티를 생성할 때 우리는 관계망을 초기화 해야 합니다. 그래서 엔터티를 생성하는 프로시저를 캡슐화 하는 오브젝트를 정의하는 것은 매우 훌륭합니다.

         Repository:리파지터리는 엔터티를 관리할 책임을 가집니다. 관리란 데이터베이스로 부터 엔터티를 업데이트, 저장, 로딩하는 것을 의미합니다. 리파지터리는 특정 인터페이

스와 인터페이스를 구현하는 구상클래스 집합을 가집니다. 구상 클래스들은 어플리케이션의 영속화 레이어(persistent layer)를 캡슐화 합니다.

              Service: 도메인을 기술한 후에, 명사는 엔터티/value object 로, 동사는 메소드로 매핑할 수 있습니다. 때때로 어떤 동사들은 엔터티/value object 의 메소드로 매핑하는

것은 불합리합니다. 이런 경우에  이런 메소드들을 담는 service라는 이름의 새로운 역할을 만들 수 있습니다. 서비스는 어플리케이션의 과잉을 정의 할 것입니다. 서비스는 클라이언트에 의해 접근 될 것입니다.

이 글을 읽어 주셔서 감사합니다. DDD에 대해 잘못된 이해가 있다면, 어떤 의견도 좋으니 남겨주세요, DDD에 대한 더 많은 정보를 원한다면 이 링크(http://www.infoq.com/minibooks/domain-driven-design-quickly)를 열어 보세요.

신고

이 글을 Twitter / Facebook 에 공유하기
이 글이 유익하다면 아래의 트위터 버튼을 눌러 공유해 주시거나, 페이스북 "좋아요" 버튼을 눌러 주세요.

   


Posted by 반더빌트
TAG


티스토리 툴바