보통 많은 아키텍쳐들의 구조를 보면 계층형으로 되어 있는 것이 많다.
사실 계층형으로 되어 있으니 그냥 그러려니 하고 넘겼는데 스프링 책을 정독을 하니 계층형이 왜 좋은지를 알 것 같다.
내가 내린 결론은 테스트때문이다.
이게 무슨 소리냐고 할 수도 있다.
많은 책에서 주구장창 학문적, 철학적으로 아주 멋지게 설명을 해놓고 있지만
결국 실무에서 직접적으로 영향을 미치는 부분은 테스트를 통해 하위계층의 동작을 보증할 수 있는 것에 그 의미가 있어 보인다.
스프링 프로젝트를 보면 처음 설계시 보통 아래와 같은 구조를 가진다.
표현 계층
비지니스 계층
영속계층
각 계층이 무슨 역할을 하는지는 따로 설명하지 않겠다.
책에서는 각 계층을 구현 할 때마다 jUnut으로 테스트코드를 작성하는것을 굉장히 강조했다.
일정이 빠듯하다고 해서 테스트코드를 안짜고 상위레이어를 쌓으면 결론적으로 더 많은 시간을 낭비하게 되는 경우가 많다고 말이다.
맞는말이다.
특히 지금 실무를 하면서 뭔가 체계적이지 않고 답이 없다는 생각이 계속 들었는데 그게 정확히 뭐가 잘못됫다고 말하기는 애매한 부분이 있었는데 바로 저거였다.
계층화가 되어있지 않고 되어 있는 부분도 테스트소스가 없어서 동작을 보장하지 않는다.
결론적으로 이슈 하나하나가 더 많은 시간을 잡아 먹었고 하위계층의 문제일수록 디버깅하는데 시간이 훨씬 오래 걸렸다.
물론 처음에는 다들 테스트소스를 짜고 테스트도 하고 싶었을 것이다.
애초에 대부분 시간이 없어서 테스트코드를 못짯다고 한다.
근데 위에서 말한대로 시간이 없기 때문에 더욱 계층화와 테스트코드를 신경써야할 지도 모른다.
다음에 아키텍쳐를 짤 때 이부분을 잊지 말하야한다.
계층형구조와 각 계층별 테스트소스를 짜야한다.
이것이 기본이다.
스프링이 저런 부분을 잘 유도하도록 되어 있다는 느낌을 받았다.
뭐 엄밀히 따지면 스프링이 잘해놓았다기 보다는 저자가 잘 해놓은것이지만 말이다.
MVC가 결국 웹구조의 기본 베이스가 된 이유를 알 것같다.
MVC가 계층구조라고 하기에는 좀 무리가 있지만 결국 목적은 같다.
각 분야를 독립시켜서 테스트할 수 있도록 만든것이다.
괜히 TDD가 나온게 아니다.물론 이 문제랑은 좀 다르긴한데..ㅋㅋ
그만큼 테스트가 중요하다는 말이다.
테스트를 위해 아키텍쳐를 틀어야 할 만큼 말이다.
