DDD(Domain Driven Design) - Repository 리파지토리
반 버논의 도메인 주도 설계 구현 이라는 책을 완독하고 나서 여러가지 정리할 점들이 있는데, 그 중 하나가 레포지토리 이다. 오늘은 리파지토리에 대해서 다루어 보려고 한다. 지금 재직중인 회사나 전회사에서 일할때도 Database 중심적 설계를 바탕으로 시스템을 구축했다. 그리고 내가 가보지 못한 대부분의 회사들도 아마도 DDD 를 실무에서 적용하고 있지 않을 것이라고 감히 추측해 본다. 물론 DDD 를 실질적으로 도입하고 있는 회사도 많을 것이다. 잡소리는 그만하고, 리파지토리에 대해서 다루어 보겠다. 반 버논의 도메인 주도 설계 구현에서 리파지토리에 아래와 같이 2 가지를 다루고 있다. - 컬렉션 지향 리파지토리 ( collection-oriented-repository ) - 영속성 지향 리파지토리 ( persistence-oriented-repository ) 먼저, 컬렉션 지향 리파지토리이다. 책에서는, 컬렉션 지향 리파지토리는 Set 컬렉션을 흉내 내야 한다고 한다. 이 말이 무슨 말이냐면, Set에 있는 같은 객체(equals and hashcode)의 인스턴스는 두 번 추가되로록 허용해서는 안 된다. 또한 리파지토리로부터 객체를 가져오게 하고 수정할 때 이를 리파지토리에 "재저장" 할 필요가 없다. 이를 단순하게 이해하기 위해서, 책에서 나온 예제를 살펴보겠다. 표준 java.util.HashSet 을 확장하고 고유 식별자로 특정 객체를 찾도록 해주는 새로운 타입상의 메서드를 생성한다고 한다. 확장 클래스로 CalendarRepository 라는 이름을 주어 인식할 수 있도록 해주었다. 하지만 이는 단순한 인메모리 HashSet 이다. 리파지토리에서 find 를 통해서 찾은 객체를 수정한 뒤, 명시적으로 다시 add 해주지 않는다. 수정내역은 해당 객체에서 바로 일어나기 때문이다. 이와 관련된 예제로 직접 작성해보았다. 아래에서 확인할 수 있듯이, me 라는 User 타입의 객체의 n...
