기록들 https://github.com/ndgndg91

DDD 를 알기전에는 나역시 그랬고, 반 버논의 도메인 주도 설계 구현에서도 언급한 내용이 있다. 바로 "개발자는 도메인보다 데이터에 초점을 맞추려는 경향이 있다." 소프트웨어 개발에 관한 대부분의 접근법이 데이터베이스에 중점을 두기 때문에, DDD를 처음 접하는 사람에게 일어날 수 있는 현상이라고 한다. 나도 매우 동의한다. 지금까지 그렇게 해왔다. 풍부한 행동을 바탕으로 도메인 개념을 설계하지 않고, 데이터의 속성(컬럼)과 연결(외래 키)을 먼저 생각하려 한다. 이를 바탕으로 데이터 모델을 대응하는 객체로 투영하게 되는데, 이로 인해 게터와 세터로 가득찬 무기력한 도메인이 되버린다. 지금부터 엔터티란 무엇인가에 대해서 다루어 보려고한다. 1. 엔터티는 식별자 를 가진다. 2. 엔터티는 변화 가능성(mutability) 을 가진다. -> 엔터티는 고유한 대상으로 긴 시간에 걸쳐 계속해서 변화한다. 어떤 예를 들 수 있을까? 지금 재직 중인 회사에서 엔터티로 다룰 수 있다면, 제일 먼저 생각나는 엔터티는 Order(주문) 이다. 특정 식별자를 가진 주문의 상태는 계속해서 변화한다. 객체를 특성(attribute) 이 아니라 식별자에 따라 구분한다면, 모델을 정의할 때 이를 우선적으로 다루어야 한다고 한다. 클래스의 정의를 단순하게 유지하면서 수명주기의 지속성(continuity)과 식별자에 집중해야 한다고 한다. 형태나 히스토리에 상관없이, 각 객체를 구분하는 수단을 정의해야 한다고 한다. 이 모델에선 같은 대상이 된다(아마도 equals and hashcode 를 의미하는 것 같다)는 의미가 무엇인지 반드시 정의해야 함을 강조하고 있다. 앞서, 엔터티는 식별자를 가지고 변화 가능성을 가진다고 했다. 따라서 시간이 흘러도 고유성(uniqueness) 을 보장할 수 있도록, 식별자를 구현하는 방법들을 확보하는 것이 중요하다. 그렇다면, 식별자를 구현하는 방법에는 어떤것들이 있을까? 1. 사용자가 식별자를...

반 버논의 도메인 주도 설계 구현 이라는 책을 완독하고 나서 여러가지 정리할 점들이 있는데, 그 중 하나가 레포지토리 이다. 오늘은 리파지토리에 대해서 다루어 보려고 한다. 지금 재직중인 회사나 전회사에서 일할때도 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...