자바스프링 개발자를 위한 실용주의 8. 레이어드 아키텍처

아키텍처는 제약조건 즉, 규칙이다. 아키텍처를 만드는 이유는 목적을 달성하기 위해서이다. 강제적인 규칙같지만 유연하게 채택한다. 아키텍처에 집중하다 보면 목적 달성에서 멀어질 수 있기 때문이다.

잘못된 레이어드 아키텍처

개발을 시작할 때 어느 레이어를 우선적으로 접근할까? 아래는 잘못된 접근을 설명한다.

• JPA Entity우선 접근
  • 데이터베이스에 종속되기 쉬움. 데이터 관점에서 시작하게 되므로 행동을 생각하기 보다는 속성에 집중하게 될 우려가 있다.

• API 엔드포인트 우선접근
  • JPA보다는 낫다. 도메인 요구사항 관점에서 보기 시작한다. 하지만 JPA Entity우선 접근과 동일하게, “행동”보다는 도메인이 가질 속성에 집중할 가능이 높다.

위 둘의 접근은 기술 스펙을 결정하는 일이다.

• [JPA Entity우선 접근]은 데이터 접근을 할 때 JPA를 사용하는 것으로 결정하게 된다.
• [API앤드포인트] 우선접근은 API라는 기술로 결정하게된다.

세부사항의 결정을 미룰 수 있는 설계가 좋은 설계이다.

-마틴 파울러

Spring, API 개발자가 아닌 백앤드 개발자가 되어야 한다.

진화하는 아키텍처

위에서 잘못된 개발 순서를 설명했다. 엔드포인트나 JPA를 우선 개발하는 것은 세부사항을 미리 결정하게 한다. 세부사항의 결정은 미룰 수 있는 설계가 좋은 설계이다.

 

그러므로 시스템 개발의 첫 시작을 도메인으로 두어야 한다. 이전에 도메인 모델링을 배우면서 행동, 책임, 협력 등을 배웠다. 그것은 도메인에 대한 논리적인 접근이다. 기술과 관련된 세부사항을 다루지 않는다. 즉, 도메인은 의존 관계 없이 순수한 모델로 개발되어야 한다.

 

아래의 그림을 보자.

도메인 계층은 어느 계층에도 의존하지 않는다. 타 계층에서 도메인 계층을 사용하기만 한다. 이렇게 되면 도메인 개발이 우선적으로 가능하다. 기술의 선택을 미루게 되므로 도메인에 집중할 수 있다.

 

어플리케이션 서비스는 도메인들이 협력하는 공간이다. 이곳에서도 기술을 선택하면 안된다. 즉, 인프라스트럭처의 클래스를 직접 사용하면 안된다. 그러므로 인프라스트럭쳐를 사용하지 않고 Repository interface를 두어 의존성 역전을 했다(DIP). 이로써 참조 방향이 반대로 전환되며, 서비스도 인프라스트럭처에 의존적이지않게 되었다.