# 리포지토리를 분리해서 설계하기

아래와 같은 이유라면 리포지토리 클래스를 분리하는 것을 고려해보자.

* 핵심 비즈니스 도메인을 다루는 리포지토리
* 읽기 전용 쿼리용 리포지토리
* 쓰기 전용 쿼리용 리포지토리
* 화면에 맞춘 복잡한 조회 쿼리용 리포지토리
* 통계용 쿼리
* 변경의 이유가 다른, 수정의 라이프 사이클이 다른 경우

{% hint style="info" %}
중요한 것은 리포지토리를 용도나 관리 포인트에 따라서 분리하는 것이 코드 유지보수, 복잡성 관리에서 유리하다는 것을 알아야 하는 것이다.
{% endhint %}

## 분리하는 것이 좋은 이유

리포지토리 클래스는 기능에 따라 점점 비대해질 수 있다. 그러면 핵심 비즈니스를 처리하기 위해 어떤 쿼리 메서드를 사용해야할 지 복잡해 질 수 있다.

특히, 화면을 위한 복잡한 조회 쿼리들은 작성 시점이 지난 후에는 그 자체만으로 이해하고 유지보수하기 어렵다. \
따라서, 별도의 클래스로 분리해서 관리하고 화면이 변경되거나 삭제 될 때 같이 정리해주는 것이 좋다. 

또한, 수정의 라이프 사이클 측면에서도 핵심 비즈니스 로직과 화면을 위한 쿼리는 다르다.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://programmer-jjy.gitbook.io/second-brain/second-brain/architecture/undefined.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.