엔터프라이즈 어플리케이션 아키텍처 패턴을 오랜만에 다시 읽고 있다. 가장 처음 다뤄지는 내용은 계층화인데, 여기서 언급되는 계층화의 이점을 보다가 좀 더 찾아보니, Martin Folwer 아저씨의 글, PresentationDomainDataLayering이 좋은 참고가 되어 기록한다.

일단, 책에서 계층화라는 용어가 사용되긴 했지만, 책 전반에 걸쳐 다뤄지는 계층은 다름 아닌 프레젠테이션, 도메인, 데이터이다. 따라서, 이 3가지 계층을 제목으로 하고 있는 Martin Fowler 아저씨의 글이 전혀 다른 주제가 아니다. 오히려 엔터프라이즈 어플리케이션 아키텍처에서의 계층화를 좀 더 잘 설명하고 있다.

각 계층에 대한 설명

계층화의 이점에 앞서, 각 계층의 의미를 간단히 살펴보자. 엔터프라이즈 어플리케이션 아키텍처 패턴의 설명을 참고하면 다음과 같다.

프레젠테이션Presentation

  • 사용자와 소프트웨어 간 상호작용을 처리함.
  • HTML 브라우저가 대표적이며,
  • 사용자에게 정보를 표시하고 사용자의 명령을 도메인과 데이터 원본으로 넘김.

도메인Domain

  • 입력 및 저장 데이터를 기반으로 하는 계산,
  • 프레젠테션에서 전달된 데이터 유효성 검증,
  • 프레젠테이션의 명령을 기반으로 작업될 데이터 원본 논리 결정 등을 수행함.

데이터Data

  • 애플리케이션을 대신해 다른 시스템과 통신함.
  • 다른 시스템이란 데이터 베이스, 또다른 애플리케이션, 트랜잭션 모니터, 메시징 시스템 등을 가리킴.

*책에서는 데이터 원본이라는 용어를 사용하는데, 영어로는 Data Source이다. 왜 원본이라고 번역했을까? 말 그대로 데이터 원천, 또는 소스라고 번역했어야 하지 않았을까? 아니면, 차라리 데이터 접근 계층이라고 과감하게 번역했으면 어땠을까 싶다.

계층화의 이점

이제부터는 계층화의 이점을 살펴보자. 가장 먼저 언급되는 이점은, 한번에 한 가지에만 집중할 수 있다는 점이다.

It’s biggest advantage (for me) is that it allows me to reduce the scope of my attention by allowing me to think about the three topics relatively independently. (중략) I narrow the scope of my thinking in each piece, which makes it easier for me to follow what I need to do.

가장 큰 이점은, 3개의 주제를 상대적으로 독립적으로 생각할 수 있게 해주어 집중의 범위를 줄여준다는 점이다. (중략) 각각의 조각으로 생각의 범위를 줄이고, 이로 인해 내가 필요로 하는 것을 좀 더 쉽게 따라갈 수 있다.

또한, 아래의 인용처럼, 변경사항이 하나의 레이어로만 제한되는 것이 아님에도(오히려 같이 변경되는 것을 일반적이라고 받아들임), 계층화된 것이 변화를 더 쉽게 만들어준다고 한다.

but when refining the UX I need to change the domain which necessitates a change to the data layer. But even with that kind of cross-layer iteration, I find it easier to focus on one layer at a time as I make changes.

하지만 UX를 개선할 때 도메인도 함께 수정해야 한다. 이는 데이터 레이어에도 변경을 불가피하게 만든다. 하지만 이같은 레이어를 넘나드는 변경(*역자주. 전체 문맥상 iteration을 ‘반복’이라고 번역해야 하지만, 짧은 문맥만을 가져온 상황에서는 ‘변경’이 더 적절하다고 판단)에도, 한 번에 하나의 레이어에만 집중하여 변경하는 것이 훨씬 더 쉽다.

그 이외에도 2가지 장점을 더 이야기하고 있다. 먼저, 모듈의 대체 가능성substitutability이다.

Another reason to modularize is to allow me to substitute different implementations of modules. This separation allows me to build multiple presentations on top of the same domain logic without duplicating it.

또다른 모듈화의 이점은 모듈 구현을 쉽게 대체할 수 있다는 점이다. 이러한 분리는 여러 프리젠테이션 작성시, 중복을 피하고 동일한 도메인 로직을 재사용할 수 있게 해준다.

마지막 한가지는 테스트 용이성이다.

Modularity also supports testability, (중략) UI code is often tricky to test, so it’s good to get as much logic as you can into a domain layer which is easily tested without having to do gymnastics to access the program through a UI [1]. Data access is often slow and awkward, so using TestDoubles around the data layer often makes domain logic testing much easier and responsive.

모듈화는 또한 테스트 용이성을 돕는다. (중략) UI 코드는 종종 테스트하기 어려우며, 따라서 가능한 많은 로직을 테스트가 용이한 도메인 레이어에 두는 것이 좋다(UI를 통해 프로그램에 접근하기 위한 부가적 노력을 기울이지 않고도 말이다). 데이터 접근은 종종 느리고 불편하므로, 데이터 레이어에 TestDoubles을 사용하여 도메인 로직 테스트를 좀 더 반응성 있고 쉽게 만들 수 있다.

참고로, Martin Fowler 아저씨는 모듈의 대체가능성과 테스트 용이성이 분명 이점이긴 하지만, 집중의 범위가 줄어든 것의 이점을 다시 한 번 강조하고 있다. 그 외에도, 레이어가 어떻게 더 나눠질 수 있을지, 그리고 최상위 레벨 모듈화를 무엇으로 하면 좋을지, 팀을 어떻게 구성해야 하는지 등에 대해 이야기하고 있다. 한 번쯤 읽어두면 도움이 되는 내용들이다. 마지막으로, 인상 깊었던 구절 하나를 기록하며 마무리한다.

“Developers don’t have to be full-stack but teams should be.”