<div id="readability-page-1" class="page"><div id="content">
		<main id="main" role="main">

		
			<article id="post-1713">
			
		<div>
			
<h2 id="저장소-패턴">저장소 패턴</h2>



<p>저장소 패턴은 데이터 저장소를 간단한 형태로 추상화한 것이다. 이를 통해 모델과 저장소를 분리할 수 있고, 저장소에 대한 테스트를 용이하게 해준다.</p>



<p>저장소 패턴을 적용하기 전에 먼저 저장소를 사용해야 되는지 확인한다. 우리가 구현할 시스템에 저장소가 필요하다면, 최소 기능 제품(minimum viable product)을 만들기 위해 추상화된 저장소를 구상해야 한다. </p>



<p>예로 들어 웹 서비스라면 웹 API가 최소 기능 제품이 된다. 책에선 할당 기능의 엔드포인트를 보여준다. 여기서 batch를 저장소에서 가져와서 새로 할당한 후에 저장하는 걸로 구상했기 때문에, 추상화된 저장소 또한 batch를 가져오고 저장하는 기능이 필요하다.</p>



<h3 id="데이터-접근에-dip-적용하기">데이터 접근에 DIP 적용하기</h3>



<p>일반적으로 UI-로직-데이터베이스 가 필요한 시스템을 구상할 때, 계층 아키텍쳐를 적용한다. 하지만 실제로 로직 부분인 도메인 모델에는 어떤 의존성이 생기지 않는게 좋다. 정확히는 어떤 상태가 있는 의존성은 없어야 된다는 말이다. 예로 들어 helper 라이브러리는 괜찮지만 ORM이나 프레임워크에 의존해선 안된다는 말이다. 따라서 UI와 데이터베이스에서 비즈니스 로직을 일방적으로 의존하는 계층 구조를 취한다. 이를 양파 아키텍쳐라 부른다.</p>



<figure><img src="https://i1.wp.com/www.cosmicpython.com/book/images/apwp_0203.png" alt="양파 아키텍쳐"></figure>



<h3 id="주의하기-orm에-의존하는-모델">주의하기: ORM에 의존하는 모델</h3>



<p>ORM은 SQL 대신 OOP의 방식으로 데이터베이스에 접근해줄 수 있게 해주는 프레임워크이다. 따라서 가장 중요한 기능이 ‘영속성 무지'(persistence ignorance)다. 도메인 모델이 어떻게 영속화되는지 알 필요가 없게 해준다. 이를 통해 특정 데이터베이스 기술에 도메인이 직접 의존하지 않도록 유지할 수 있다.</p>



<p>하지만 ORM의 튜토리얼을 보면 도메인 모델을 ORM의 프로퍼티에 기반해서 도메인 모델을 만들게 된다. 그러면 오히려 ORM에 의존하는 모델을 만들게 된다. 그에 따른 문제점으로 도메인 모델이 객체 지향이 아닌 다른 게 필요한다면 ORM 때문에 벗어나기 어려워진다는 게 있다. (이것도 Python을 사용하기 때문에 고려한 문제라고 본다.) 그리고 도메인 모델을 테이블로 매핑하는 방법을 원하는대로 제어하기 힘들다.</p>



<h3 id="저장소-패턴-적용하기">저장소 패턴 적용하기</h3>



<p>책에선 ORM이 아닌 조금 예전 방식인 mapper를 사용한다. 이럴 경우, mapper는 도메인 모델에 종속되지만 반대로 도메인 모델에선 mapper를 알지 못한다. 덕분에 만약 우리가 다른 ORM을 사용한다고 하더라도 도메인 모델은 수정되지 않는다.</p>



<p>저장소를 추상화 하기 전에 먼저 데이터베이스에 접근하기 위해 사용하는 도구들이 정상 작동하는지 테스트한다. 예로 들어 mapper가 제대로 작동하는지 SQL 구문을 같이 호출해서 검증하는 테스트 코드를 짤 수 있다.</p>



<p>그 후에 어떻게 추상화할 건지 생각해보자. 위에서 본 batch의 경우, 저장을 위한 add()와 가져오기 위한 save()가 필요하다. 그렇다면 이에 맞춰서 저장소의 인터페이스를 만들면 된다.</p>



<p>Python에선 ABC(추상 기반 클래스)와 duck typing, <a href="https://www.python.org/dev/peps/pep-0544/">프로토콜</a> 로 추상화된 저장소를 구현할 수 있다. ABC는 무시하고 코딩하기 쉬워서 보통은 duck typing에 의존해서 추상화를 구현한다. 프로토콜은 상속을 사용하지 않고 타입을 지정할 수 있는 대안이다. 특히 상속보다 구성(composition)이라는 규칙을 선호한다면 좋은 대안이다.</p>



<p>추상화된 저장소를 만들었다면, 다음은 저장소 구현체에 대한 테스트를 먼저 짠다. 정말로 구현체를 통해 DB와 연결되었는지 확인하기 위해 SQL문의 실행 결과와 구현체의 결과가 같은지 검증한다.</p>



<p>테스트를 만들었다면 이 테스트를 통과하기 위한 구현체를 만든다.</p>



<p>책에서는 ‘포트’와 ‘어댑터’라는 용어를 쓴다. ‘포트’는 애플리케이션과 추상화 대상 사이의 인터페이스를 말하고, ‘어댑터’는 이 인터페이스 뒤에 있는 구현체를 말한다.</p>



<h3 id="트레이드오프">트레이드오프</h3>



<p>아키텍쳐 패턴을 적용할 때 반드시 뒤따라오는 대가도 고려해야 한다.</p>



<p>위에서 ORM 의존 모델 대신 저장소를 추상화하겠다는 패턴을 적용할 때는 전체적인 복잡도는 줄어들 수 있다. 그 덕분에 여러 종류의 저장소를 쓸 때나 테스트를 위한 가짜 저장소를 만들 때, 도메인 모델이 영향받지 않을 수 있다.</p>



<p>하지만 이 패턴도 단점이 있다. ORM 의존 모델의 경우, 수동으로 매핑한 코드를 만들고 유지보수하는 비용이 발생하지 않는다. 마지막으로 ORM이 지원하는 데이터베이스 범위 내에서의 변경이라면 ORM도 도메인 모델과 저장소 사이의 의존성 문제를 이미 해결해주고 있다.</p>



<p>책에선 그 트레이드오프를 다음과 같은 그래프로 보여준다.</p>



<figure><img src="https://i0.wp.com/www.cosmicpython.com/book/images/apwp_0206.png" alt="apwp 0206"></figure>



<p>여기까지가 저장소 패턴에 대한 내용이다. 다음은 서비스 계층으로 넘어갈 것이다.</p>
			
			
								</div>
</article>

			
	
			

		
		</main>
	</div></div>

Wraithkim의 지식공방

저장소 패턴 저장소 패턴은 데이터 저장소를 간단한 형태로 추상화한 것이다. 이를 통해 모델과 저장소를 분리할 수 있고, 저장소에 대한 테스트를 용이하게 해준다. 저장소 패턴을 적용하기 전에 먼저 저장소를 사용해야 되는지 확인한다. 우리가 구현할 시스템에 저장소가 필요하다면, 최소 기능 제품(minimum viable product)을 만들기 위해 추상화된 저장소를 구상해야 한다. 예로 들어 웹 서비스라면 웹 API가 최소 기능 […]

Architecture Patterns with Python – 3

댓글