파이썬으로 살펴보는 아키텍처 패턴

202

2

부

이벤트 기반 아키텍처

파라미터를 도메인 객체에서 기본 타입으로 바꾸면 연결을 멋지게 끊을 수 있다. 클라이언트 코

드는 더 이상 도메인과 직접 묶이지 않고, 그에 따라 모델을 변경해도 서비스 계층은

API

를 변경

하지 않고 예전과 같이 그대로 제공할 수 있고, 반대로

API

가 변경돼도 모델은 그대로 남겨둘 수

있다.

그렇다면 (이벤트 도입이) 반대방향으로 다시 돌아가는 것일까? 하지만 핵심 도메인 모델은 여

전히 다른 계층과 관계없이 바뀔 수 있다. 이벤트 도입은 외부 세계와 이벤트 클래스를 연결할

뿐이다. 이벤트도 도메인의 일부분이지만 이벤트는 도메인에 비해 훨씬 덜 자주 바뀔 것이라고

예상하면 연결을 해도 어느정도 타당한 대상이라 할 수 있다.

이벤트를 도입하면 어떤 이익이 있을까? 이제는 애플리케이션의 어떤 유스 케이스를 호출할 때

기본 타입들의 특정 조합을 기억할 필요가 없다. 단지 애플리케이션에 대한 입력을 표현하는 단

일 이벤트 클래스를 사용하면 된다. 이는 개념적으로는 아주 훌륭하다. 부록

E

를 보면 알 수 있

듯이 이런 이벤트 클래스는 입력값을 검증할 수 있는 아주 좋은 장소이기도 한다.

9.2.1

메시지 버스는 이제 이벤트를

UoW

로부터 수집한다

이벤트 핸들러는 이제

UoW

가 필요하다. 추가로 애플리케이션에서 메시지 버스는 더 중심 ...