리포지토리 1 의 계속

리포지토리 2

도메인 기반 설계의 목표는 기술이 아닌 도메인에 대한 모델에 초점을 맞추어 더 나은 소프트웨어를 만드는 것입니다. (제2부 제6장부터)

따라서 클라이언트 (특히 "응용 프로그램 계층")가 직접 데이터베이스 쿼리에 액세스하면 모델이 아니라 기술을 다루고 있으며, 집계 및 객체 캡슐화를 우회하고 모델이 단순한 데이터 넣어 버립니다.

클라이언트가 필요한 것은 이미 존재하는 도메인 객체에 대한 참조를 얻는 실용적인 수단 (제 2 6 장에서)

지속된 오브젝트는 수명 주기의 중기입니다.
그래서 데이터베이스 기술을 사용하여 객체를 "생성"하는 것이 아니라, 뭐든지 좋기 때문에, "이미 있는 객체"의 참조를 손에 넣는 것이 중요합니다.

오히려 객체가 "이미있는"것으로 원활하게 객체 참조를 얻을 수 있도록 구현하고 싶은 것입니다.

메모리에 있다고 착각하게 하는 것(제2부 제6장부터)

리포지토리 패턴은 이를 위해 사용됩니다.

쿼리에서 무엇을 얻는 방법

기본 SQL에서 어떤 값을 얻는 쿼리를 작성해도 자유롭습니다.

그러나 도메인 중심 설계에서는 특히 값 객체가 집계의 루트에서 추적되어야 합니다.
그것은 영속화된 객체에서도 마찬가지이며,

영속화된 값 객체를 찾으려면, 그것을 캡슐화하는 집계의 루트로서 기능하는 엔티티로부터 관련을 추적하는 것이 보통이다. (제2부 제6장부터)

위에서 클라이언트가 직접 쿼리를 사용하면 이러한 도메인 중심 설계의 이점을 살린 객체의 활용법에서 벗어나 뭐든지 글로벌하게 취득하게 되어 버립니다.

저장소 패턴을 사용하는 또 다른 이유는 집계 단위로 개체를 재구성하기 때문입니다.
(예외로서, "열거"의 취득 등, 드물지만, 값 오브젝트를 쿼리로 취득하는 일이 있습니다)

리포지토리 패턴

리포지토리는 이전에 읽은 것처럼 쿼리와 같은 기술 솔루션을 캡슐화합니다.

간단한 모델은 다음과 같은 느낌입니다.



내일도 계속 리포지토리를 읽어 갑니다.