Layered architecture 문제

Layered architecture는 데이터베이스 주도 설계를 유도한다

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

웹 계층은 도메인 계층에 의존하고, 도메인 계층은 영속성 계층에 의존하게 된다. 그래서 자연스레 데이터베이스에 의존하게 된다.

필자도 Spring boot로 개발하면서 해당 내용에 너무 공감이 되었다.
비즈니스 로직에 엔티티를 끌어와서 Dirty Check를 유도한다던지 DTO를 활용하여 웹 계층에 옮긴다는 명목하에 도메인 계층에 엔티티를 넣는 경우가 다반사였다.

그러한 원인은 ORM 프레임워크 도입이 주된 원인이었다.

이렇게 되면 영속성 계층과 도메인 계층의 강력한 결합이 생긴다.
이러한 이유로 영속성 관련 작업들이 도메인 계층에 침범하게 된다.

지름길을 택하기 쉬워진다.

전통적인 계층형 아키텍처에서 전체적으로 적용되는 유일한 규칙은, 특정한 계층에서는 같은 계층에 있는 컴포넌트나 아래에 있는 계층에만 접근이 가능하다.

레이어드 아키텍처의 느슨한(?) 규칙은 특정 계층이 점점 비대해지는 현상이 발생한다.
그리고 도메인 간의 관계를 잘못 파악하면 순환 참조의 걸리기 쉬운 구조라고 생각한다.

그러한 이유로 팀원들간의 실력이 뛰어나 계층간의 결합도를 낮추어 개발하면 모두 해피하지만 그렇지 못한 경우는 위의 다이어그램과 같이 되는 경우가 대부분일 것 같다.

테스트하기 어려워진다.

엔티티의 필드를 단 하나만 조작하면 되는 경우에 웹 계층에서 바로 영속성 계층에 접근하면 도메인 계층을 건드릴 필요가 없지 않을까?

필자도 개발 초기에는 위와 같은 생각을 많이 했던 것 같다.
필드를 추가 및 제거하는 작업 자체가 없으면 제일 좋은 거 아닌가 하는 생각이었지만 어떤 변화에도 유연하게 대처할 수 있는 아키텍처로서는 꽝이라는 사실을 뒤늦게 깨달았다.

문제점

1. 유스케이스가 추가되면 책임이 섞이고 핵심 도메인 로직들이 퍼져나갈 확률이 높다
2. 웹 계층에서 도메인 계층 뿐만 아니라 영속성 계층도 모킹을 해줘야 한다.

유스케이스를 숨긴다.

개발자들은 새로운 유스케이스를 구현하는 새오운 코드를 선호한다.
그러나 실제로는 새로운 코드를 짜는 데 시간을 쓰기보다는 기존 코드를 바꾸는 데 더 많은 시간을 쓴다.

계층형 아키텍처는 도메인 서비스의 너비에 관한 규칙을 강제하지 않는다.
위의 그림처럼 유스케이스가 엄청 많아져 비대해진 서비스가 탄생하게 된다.
이처럼 비대해진 서비스를 실무에서 만든 적이 있었고 비대해진 서비스가 너무 많은 책임을 가져서 곤란한 경험이 많았다.

동시 작업이 어려워진다.

지연되는 소프트웨어 프로젝트에 인력을 더하는 것은 개발을 늦출 뿐이다.

레이어드 아키텍처의 추가적인 문제점은 하나의 기능당 하나의 사람이 투입 되어야 수월하다는 것이다.
데이터베이스 주도 개발이 되는 경우가 많아서 해당 영속성 계층을 먼저 작업을 해주어야 다음 도메인 계층과 웹 계층이 올라가는 방식이 된다.
물론 개발자들이 인터페이스를 먼저 같이 정의하면 되지 않을까? 의문이 생기지만 그런 경우는 데이터베이스 주도 설계를 하지 않은 경우에만 해당된다.
그리고 비대해진 도메인 계층을 같이 작업 하다보면 merge conflict가 엄청 많이 난다....

유지보수 가능한 소프트웨어를 만드는 데 어떻게 도움이 될까?

계층형 아키텍처는 많은 것들이 잘못된 방향으로 흘러가도록 용인한다.

아주 엄격한 자기 훈련 없이는 시간이 지날수록 품질이 저하되고 유지보수하기가 어려워지기 쉽다.

결론적으로 지름길을 택하지 않고 유지보수하기에 더 쉬운 솔루션을 택하자!!