전통적인 웹 애플리케이션 구조
•
일반적인 3계층 아키텍처를 표현한 그림
•
웹 계층에서 요청을 받아 도메인 혹은 비즈니스 계층에 있는 서비스로 요청을 보낸다.
•
서비스에서는 필요한 비즈니스 로직을 수행하고, 도메인 엔티티의 현재 상태를 조회하거나 변경하기 위해 영속성 계층의 컴포넌트를 호출한다.
→ 사실 계층형 아키텍처는 견고한 아키텍처 패턴
•
이를 잘 이해하고 구성한다면, 다른 계층에 영향 없이 독립적으로 도메인 로직을 작성할 수 있다.
그럼 어떤 문제가 있을까?
계층형 아키텍처는 데이터베이스 주도 설계를 유도한다
•
계층형 아키텍처의 토대는 데이터베이스다.
•
웹 계층은 도메인 계층에 의존하고, 도메인 계층은 영속성 계층에 의존하기 때문에 결국 데이터베이스에 의존하게 된다.
→ 모든 것이 영속성 계층을 토대로 만들어진다.
우리가 만드는 애플리케이션의 목적은 무엇일까?
•
일반적으로 비즈니스를 관장하는 규칙이나 정책을 반영한 모델을 만들고,
•
사용자가 이러한 규칙과 정책을 더욱 편리하게 활용할 수 있게 한다.
•
즉, 우리는 상태(state)가 아니라 행동(behavior)을 중심으로 모델링한다.
→ 어떤 애플리케이션이든 상태가 중요한 요소이긴 하지만 행동이 상태를 바꾸는 주체이기 때문에 행동이 비즈니스를 이끌어간다.
그렇다면, 우리는 왜 ‘도메인 로직’이 아닌 ‘데이터베이스’를 토대로 아키텍처를 만드는 것일까?
•
가장 큰 원인은 ORM 프레임워크를 사용하기 때문이다.
•
ORM이 안좋다는 것은 아니지만, ORM과 계층형 아키텍처를 결합하면 비즈니스 규칙을 영속성 관점과 섞고 싶은 유혹을 쉽게 받는다.
→ 이렇게 되면 영속성 계층과 도메인 계층 사이에 강한 결합이 생긴다. 서비스는 영속성 모델을 비즈니스 모델처럼 사용하게 되고, 이로 인해 영속성 계층의 기능(즉시 로딩, 지연 로딩, 변경 감지, 트랜잭션, 캐시 플러시 등) 관련 작업들을 해야만 한다.
이러한 구조는 ‘지름길을 택하기 쉽게’만든다
•
A → B → C → D로 접근해야 할때, A → C → D로 접근하면 조금 더 편한데..
◦
누군가 이렇게 해버리면, 돌이킬 수 없다
테스트하기 어려워진다
•
계층형 아키텍처를 사용할 때 일반적으로 나타나는 변화의 형태는 계층을 건너뛰는 것이다.
◦
영속성 계층의 변화가 웹과 도메인 모두에게 영향을 미친다.
◦
유스케이스가 확장된다면 더욱 복잡해진다.
동시 작업이 어려워진다
•
넓은 영역을 커버하는 엔티티, 서비스가 있다면 그들의 변경이 조심스러워진다.
•
한쪽이 완료될 때 까지 기다려야만 한다.
Conclusion
•
계층형 아키텍처가 마냥 나쁜 것만은 아니다. 규칙을 잘 적용하면 유지보수하기 매우 쉽다.
•
다만 많은 것들이 잘못된 방향으로 흘러가도록 용인한다.
•
스스로 아무 엄격하지 않는다면 시간이 지날수록 품질이 저하되고 유지보수하기가 어려워진다.
