서론.
최근 인프런에서 주최한 2024 인프콘을 다녀왔는데 거기서 토비님의 발표내용 중에 헥사고날 아키텍쳐는 스프링에 있어서 반드시 필요한 아키텍쳐라고 이야기하던 것이 기억이나서 클린 아키텍쳐의 얇은 버전(?)을 사서 읽고 있다
그 중 1장에 대한 공감가는 내용, 좋은 아이디어를 찾아서 정리한 내용이다
데이터 베이스 주도 설계 ?
- 계층형 아키텍쳐 구조
웹 계층은 요청을 받아 도메인 로직에 요청한다. 도메인은 다시 영속성 계층에게 요청한다
이 내용의 결론은 결국 모든 것이 영속성 계층을 토대로 만들어야 한다는 내용이다 또한 이런 방식은 여러가지 문제를 초래한다
개발을 할 때 도메인의 목적 즉, 만들고 있는 제품의 목적에 대해 생각하는데 코드상에서는 보통 상태(State, 객체의 로컬 변수) 가 아닌 행동(behavior, 객체의 메시지, 메서드) 를 중심으로 모델링 한다 -> 중요!
어떤 앱이든 상태도 중요하지만 행동이 상태를 변경하며 또 다른 객체에게 메시지를 전달하기 때문에 중심이 된다
그러나 계층형 아키텍쳐의 구조는 이런 관점보다 계층 ! 이라는 특정 구조에 의해 데이터베이스의 구조를 먼저 생각하고 구현하게 되도록 유도한다
여기서는 다른 무엇보다도 도메인 로직을 먼저 만들어야 만드는 자신이 로직을 제대로 이해했는지 빠른 검증이 된다고 이야기한다
(맞는 말 같다, 나역시도 ERD 먼저 설계하고 진행하며 책의 내용을 보고 이해한 내용으로는 의사코드라도 정리해서 도메인 로직을 만들어야 한다는 내용 같다)
계층은 아래 방향으로만 접근가능하므로 도메인 계층에서는 엔티티에 접근이 쉽다
하지만 이러한 구조는 영속성 계층과 도메인 계층이 강한 결합으로 묶여있게된다
(즉, 도메인 로직에서 트랜잭션 처리, 지연로딩등 영속성 계층에 대한 로직을 추가작성해야함)
영속성 코드가 사실상 도메인 코드에 녹아들어가서 둘 중 하나만 바꾸는 것이 어려워진다 (공감)
구조상 지름길을 택하기 쉬워진다 ?
- 여기서 지름길은 부정적인 의미를 이야기함
계층적 아키텍쳐는 구조상 같은 계층에 있는 컴포넌트나 아래에 있는 계층에만 접근이 가능하다는 것이다
따라서 만약 상위 계층에 위치한 컴포넌트에 접근해야 한다면 간단하게 컴포넌트를 계층 아래로 내려버리면 된다, 그러면 접근 가능하게 되고 깔끔하게 문제가 해결된다 (지름길)
위 내용처럼 하지말라는 뜻이다, 심리적으로 하지 않겠다고 다짐해도 인간은 하게되어있다 범죄가 아니니까.
그러므로 이런 지름길을 택할시 강제해야 한다. 여기서는 코드리뷰에서의 강제가 아닌 빌드자체를 하지 못하게 규칙을 만들어야 한다고 이야기한다
테스트 하기 어려워진다, 유스케이스를 숨긴다
만약 엔티티의 특정 필드 하나만 변경하는 요구사항이 생긴다면 컨트롤러에서 차라리 엔티티의 속성을 변경해서 기능을 만드는게 쉽지 않을까? 간단한 기능 이니까!
- 당연히 이렇게 하면 안된다
도메인 계층이 파편화되며 컨트롤러 테스트를 작성할 때 해당 영속성 계층까지 모킹해야하는 일이 발생한다
그리고 테스트 설정이 복잡해지면 점점 테스트를 전혀 작성하지 않게 되는 방향으로 간다 (공감)
혹은 계층형 아키텍쳐에서의 좋은 방향성은
좁은 도메인 서비스를 만들도록 지향하자 이다. 즉, 하나씩만 담당하게 한다는 것 UserService 에서 사용자 등록 유스케이스를 추가하는 대신 RegisterUserService 를 추가해보는 것도 나쁘지 않다 -> 좋은 생각같다 !
출처
- 만들면서 배우는 클린 아키텍쳐 01장
