계층형 아키텍처

Flow

1. 맨 위의 웹 계층에서 요청을 받는다.
2. 도메인 혹은 비즈니스 계층에 있는 서비스로 요청을 보낸다.
3. 서비스에서는 필요한 비즈니스 로직을 수행한다.
4. 이때 도메인 엔티티의 현재 상태를 조회하거나 변경하기 위해 영속성 계층의 컴포넌트를 호출한다.

• 잘 만들어진 계층형 아키텍처는 선택의 폭을 넓히고, 변화하는 요구사항과 외부 요인에 빠르게 적응할 수 있게 해준다.

• 일반적으로 로직 flow와 컴포넌트들의 의존성 flow가 일치하여 받아들이기 쉽다.

뭐가 문제지?

• 코드에 나쁜 습관들이 스며들기 쉽게 만든다.
• 시간이 지날수록 SW를 점점 더 변경하기 어렵게 만드는 수많은 허점들을 노출한다.

계층형 아키텍처는 데이터베이스 주도 설계를 유도한다.

• 전통적인 계층형 아키텍처의 토대는 데이터베이스

  • 위의 구조에서 의존성 구조를 따라가보면 자연스레 결국은 DB에 의존하게 될 것을 짐작할 수 있다.

• 따라서 모든 것이 결국은 영속성 계층을 토대로 만들어진다.

• 하지만 우리가 만드는 대부분의 애플리케이션은 상태가 아니라 행동을 중심으로 모델링한다.

  • 여기서 ‘상태 → 영속성, 행동 → 도메인 로직’ 으로 볼 수 있다.
  • 행동이 상태를 바꾸는 주체이기 때문에 행동이 비즈니스를 이끌어간다!

• 하지만 계층형 아키텍처는 데이터베이스의 구조를 먼저 생각하고, 이를 토대로 도메인 로직을 구현하게 하는 데이터 중심적 사고를 유발한다.

• 비즈니스 관점에서는 전혀 맞지 않는 방법이다.

  • 도메인 로직을 먼저 만들어야한다! → 우리가 로직을 제대로 이해했는지 확인 가능
  • 도메인 로직이 맞다는 것을 확인한 후, 이를 기반으로 영속성 계층과 웹 계층을 만들어야한다!

• 이런 데이터베이스 중심적인 아키텍처가 만들어지는 가장 큰 원인은 → ORM

  • ORM + 계층형 아키텍처 ⇒ 비즈니스 규칙을 영속성 관점과 섞고 싶은 유혹