DDD - Aggregate, Factory, Repository

모든 객체는 생명주기가 있다. 일반적으로 객체는 생성자를 호출해서 만들어진 다음 가비지 컬렉터에서 삭제된다. 그러나 엔티티의 경우는 더욱 오래 지속되며, 메모리안에서만 시간을 보내지 않는다. 그리고 각 엔티티들은 상호의존성을 갖는다. 이러한 객체들을 관리하는데 실패한다면 도메인주도개발을 시도하는 것에 쉽게 좌절될 수 있다.

AGGREGATE

어그리게이트는 우리가 데이터 변경의 단위로 다루는 연관 객체의 묶음을 말한다. 각 AGGREGATE는 루트와 바운더리가 있다. 루트는 단 하나만 존재하며 외부에서 객체를 참조할때는 어그리게이트 루트만을 통해서 이루어져야만 한다. 또한 삭제와 변경도 어그리게이트 루트를 통해서만 이루어져야 한다. 외부객체는 어그리게이트 루트만 접근할 수 있게 하고 내부만 감춰야만 한다. -> 밥 아저씨의 의견도 동일하다. 즉 리파지토리는 어그리게이트를 기준으로 생성되어야 한다. -> 작업 리파지토리는 있지만 스텝 리파지토리는 없다.

FACTORY

경축! 아무것도 안하여 에스천사게임즈가 새로운 모습으로 재오픈 하였습니다.
어린이용이며, 설치가 필요없는 브라우저 게임입니다.
https://s1004games.com

어떤 객체나 전체 AGGREATE를 생성하는 일이 복잡하다면 팩토리를 이용해 이것을 캡슐화 할 수 있다. 팩토리도 도메인 계층에 있어야 한다. 클라이언트에서 객체를 조립한다면 캡슐화를 위반할 수 있다. 팩토리는 불변식 검사를 생성물에 위임할 수 있으며 일반적으로 이렇게 하는 것이 최선이다. 엔티티가 자신의 상태가 올바르도록 유지를 해야 한다는 의미이다. 

REPOSITORY

필요한 객체를 찾기 위한 진입점이 리파지토리이다. 데이터베이스에 너무 많은 질의를 하지 마라. 이러면 도메인 로직은 질의와 클라이언트 코드로 들어가고, 엔티티와 VO는 DTO로 전락하게 될 것이다. 어그리게이트의 루트에만 리파지토리를 제공하고, 객체 저장과 접근은 리파지토리에 위임하자 그리고 우리는 모델에만 집중하자. -> 범균님 왈 그냥 Map객체에 해당 객체들이 유지되고 있다고만 생각하라. 맵에 대고 질의를 할 수 있는가?