<div id="readability-page-1" class="page"><div>
  <main>
    <h3 id="프로젝트의-아키텍처를-변경하기">프로젝트의 아키텍처를 변경하기</h3>
<hr>
<ul>
<li>
<p>이미 큰 진흙공을 만든 상태라면 상황을 개선하는 것은 어려울 수 있다. 실제로는 한번에 하나씩 대상을 개선해야 한다.</p>
</li>
<li>
<p>중요한 일부터 먼저 처리해보자. 여러분은 ‘여러분이 해야하는 문제가 무엇인가’, ‘여러분이 맏는 소프트웨어가 변경하기 어렵지는 않은가’, ‘성능이 받아들일 수 없을 정도인가’, ‘이해할 수 없을 정도로 이상한 버그가 있는가’등과 같은 질문을 던져볼 수 있다.</p>
</li>
<li>
<p>마음속에 명확한 목표가 있어야지 수행해야 하는 작업의 우선순우를 정할 수 있다. 더 중요한 것은 목표가 있어야 다른 팀원들에게 수행하는 이유를 명확히 설명할 수 있다는 것이다.</p>
</li>
</ul>
<h3 id="뒤엉킨-책임-분리">뒤엉킨 책임 분리</h3>
<hr>
<ul>
<li>
<p>이 책의 앞부분에서 큰 진흙공의 주요 특성으로 균일성에 대해서 설명했다. 각 컴포넌트의 책임이 명확하지 않아서 시스템의 모든 부분이 똑같아 보인다. 이런 문제를 해결하려면 책임을 분리하고 명확한 경계를 그어야 한다. 가장 먼저 서비스 계층을 만드는 일을 할 수 있다.</p>
</li>
<li>
<p>시스템의 유스케이스를 알아내는 것 부터 시작해보자. 사용자 인터페이스가 있다면 이 인터페이스는 어떤 일을 수행하는가? 백엔드 처리 컴포넌트가 있다면 각 크론잡이나 셀러리 잡이 단일 유스케이스일 것이다.</p>
</li>
<li>
<p>이런식으로 지원되는 각 연산에 대한 함수나 클래스를 하나씩 만드는 것을 목표로 한다. 이 함수나 클래스는 수행할 작업을 오케스트레이팅 한다. 각 유스케이스는 다음과 같은 작업을 한다.</p>
</li>
</ul>
<pre tabindex="0"><code>- 필요하면 자체 데이터베이스 트랜잭션을 시작한다.
- 필요한 데이터를 읽어온다.
- 전제조건을 검사한다.
- 도메인 모델을 업데이트 한다.
- 변경된 내용을 영속화 한다.
</code></pre><ul>
<li>
<p>각 유스케이스는 원자적 단위로, 실패하거나 성공해야 한다. 한 유스케이스에서 다른 유스케이스를 호출할 수도 있다. 그렇게 해도 좋다. 단지 오래 실행되는 데이터베이스 트랜잭션을 피해야 한다는 사실만 기억하길 바란다.</p>
</li>
<li>
<p>유스케이스 함수에서는 중복이 일어나도 좋다. 우리는 완벽한 코드를 작성하려는 것이 아니다. 단지 의미있는 계층을 추출하련느 것 뿐이다. 유스케이스 함수가 서로 연쇄적으로 호출하는 긴 사슬보다는 같은 코드를 몇 군데 중복하는 게 더 좋다.</p>
</li>
<li>
<p>이 시점에 도메인 모델에서 모든 데이터 접근 코드와 오케스트레이션 코드를 빼서 유스케이스로 옮길 수 있는 좋은 기회다. I/O를 신경쓰는 코드 (이메일 보내기, 파일쓰기)도 도메인 모델에서 빼서 유스케이스 함수에 넣어야 한다.</p>
</li>
<li>
<p>이런 유스케이스 함수는 대부분 로깅, 데이터 접근, 오류 처리에 대한 것이다. 이 단계를 수행하고 나면 프로그램이 실제 어떤 일을 하는지 대략 파악할 수 있고, 각 연산의 시작과 끝이 명확하게 정의됐음을 확신할 수 있다.</p>
</li>
<li>
<p>이제 순수한 도메인 모델을 만드는 것에 한걸음 더 다가갔다.</p>
</li>
</ul>
<h3 id="애그리게이트와-제한된-콘텍스트-식별하기">애그리게이트와 제한된 콘텍스트 식별하기</h3>
<hr>
<ul>
<li>
<p>애그리게이트는 일관성 경계다. 보통 각 유스 케이스는 한번에 한 애그리게이트만 업데이트 한다. 한 핸들러는 한 애그리게이트를 저장소에서 가져와서 상태를 변경한다. 그 결과로 이벤트를 발생시킨다. 시스템의 다른 부분에서 데이터를 가져와야 할 때 읽기 모델을 사요하면 아무 문제가 없지만, 한 트랜잭션 안에서 여러 애그리게이트를 업데이트 하는 일은 피하는게 좋다.</p>
</li>
<li>
<p>코드를 여러 다른 애그리게이트로 분리하기 위해서 우리는 명시적으로 여러 애그리게이트가 최종 일관성 있게 되는 방법을 선택했다.</p>
</li>
</ul>
<h3 id="스트랭글러-패턴을-통해-마이크로서비스로-전환하는-이벤트-기반-접근-방법">스트랭글러 패턴을 통해 마이크로서비스로 전환하는 이벤트 기반 접근 방법</h3>
<hr>
<ul>
<li>스트랭걸리 피그 패턴은 예전 시스템을 그대로 사용하면서 예전 시스템의 가장 자리에 새 시스템을 만드는 것으로 이루어진다. 예전 시스템이 아무런 동작도 하지 않고 꺼질때까지 예전 기능 일부를 점진적으로 가로채 새 기능으로 대치하는 과정을 계속 수행한다.</li>
</ul>
<h3 id="참고-문헌">참고 문헌</h3>
<hr>
<ul>
<li><a href="https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=271944317&amp;start=slayer">파이썬으로 살펴보는 아키텍처 패턴</a></li>
</ul>

    <a href="../../../../"> &gt;&gt; Home</a>
  </main>
</div></div>

Home on 개발자 이동욱

Lee Dong Wook

프로젝트의 아키텍처를 변경하기
이미 큰 진흙공을 만든 상태라면 상황을 개선하는 것은 어려울 수 있다. 실제로는 한번에 하나씩 대상을 개선해야 한다.
중요한 일부터 먼저 처리해보자. 여러분은 ‘여러분이 해야하는 문제가 무엇인가’, ‘여러분이 맏는 소프트웨어가 변경하기 어렵지는 않은가’, ‘성능이 받아들일 수 없을 정도인가’, ‘이해할 수 없을 정도로 이상한 버그가 있는가’등과 같은 질문을 던져볼 수 있다.
마음속에 명확한 목표가 있어야지 수행해야 하는 작업의 우선순우를 정할 수 있다. 더 중요한 것은 목표가 있어야 다른 팀원들에게 수행하는 이유를 명확히 설명할 수 있다는 것이다.
뒤엉킨 책임 분리
이 책의 앞부분에서 큰 진흙공의 주요 특성으로 균일성에 대해서 설명했다. 각 컴포넌트의 책임이 명확하지 않아서 시스템의 모든 부분이 똑같아 보인다. 이런 문제를 해결하려면 책임을 분리하고 명확한 경계를 그어야 한다. 가장 먼저 서비스 계층을 만드는 일을 할 수 있다.
시스템의 유스케이스를 알아내는 것 부터 시작해보자. 사용자 인터페이스가 있다면 이 인터페이스는 어떤 일을 수행하는가? 백엔드 처리 컴포넌트가 있다면 각 크론잡이나 셀러리 잡이 단일 유스케이스일 것이다.
이런식으로 지원되는 각 연산에 대한 함수나 클래스를 하나씩 만드는 것을 목표로 한다. 이 함수나 클래스는 수행할 작업을 오케스트레이팅 한다. 각 유스케이스는 다음과 같은 작업을 한다.
- 필요하면 자체 데이터베이스 트랜잭션을 시작한다.
- 필요한 데이터를 읽어온다.
- 전제조건을 검사한다.
- 도메인 모델을 업데이트 한다.
- 변경된 내용을 영속화 한다.
각 유스케이스는 원자적 단위로, 실패하거나 성공해야 한다. 한 유스케이스에서 다른 유스케이스를 호출할 수도 있다. 그렇게 해도 좋다. 단지 오래 실행되는 데이터베이스 트랜잭션을 피해야 한다는 사실만 기억하길 바란다.
유스케이스 함수에서는 중복이 일어나도 좋다. 우리는 완벽한 코드를 작성하려는 것이 아니다. 단지 의미있는 계층을 추출하련느 것 뿐이다. 유스케이스 함수가 서로 연쇄적으로 호출하는 긴 사슬보다는 같은 코드를 몇 군데 중복하는 게 더 좋다.
이 시점에 도메인 모델에서 모든 데이터 접근 코드와 오케스트레이션 코드를 빼서 유스케이스로 옮길 수 있는 좋은 기회다. I/O를 신경쓰는 코드 (이메일 보내기, 파일쓰기)도 도메인 모델에서 빼서 유스케이스 함수에 넣어야 한다.
이런 유스케이스 함수는 대부분 로깅, 데이터 접근, 오류 처리에 대한 것이다. 이 단계를 수행하고 나면 프로그램이 실제 어떤 일을 하는지 대략 파악할 수 있고, 각 연산의 시작과 끝이 명확하게 정의됐음을 확신할 수 있다.
이제 순수한 도메인 모델을 만드는 것에 한걸음 더 다가갔다.
애그리게이트와 제한된 콘텍스트 식별하기
애그리게이트는 일관성 경계다. 보통 각 유스 케이스는 한번에 한 애그리게이트만 업데이트 한다. 한 핸들러는 한 애그리게이트를 저장소에서 가져와서 상태를 변경한다. 그 결과로 이벤트를 발생시킨다. 시스템의 다른 부분에서 데이터를 가져와야 할 때 읽기 모델을 사요하면 아무 문제가 없지만, 한 트랜잭션 안에서 여러 애그리게이트를 업데이트 하는 일은 피하는게 좋다.
코드를 여러 다른 애그리게이트로 분리하기 위해서 우리는 명시적으로 여러 애그리게이트가 최종 일관성 있게 되는 방법을 선택했다.
스트랭글러 패턴을 통해 마이크로서비스로 전환하는 이벤트 기반 접근 방법
스트랭걸리 피그 패턴은 예전 시스템을 그대로 사용하면서 예전 시스템의 가장 자리에 새 시스템을 만드는 것으로 이루어진다. 예전 시스템이 아무런 동작도 하지 않고 꺼질때까지 예전 기능 일부를 점진적으로 가로채 새 기능으로 대치하는 과정을 계속 수행한다.
참고 문헌
파이썬으로 살펴보는 아키텍처 패턴

파이썬으로 살펴보는 아키텍처 패턴 - 현재 맡은 프로젝트에 좋은 아키텍처 적용하기

댓글