
서버 개발자로서 개발을 하게 되면 아무래도 제일 처음 접하는 프로젝트 구조는 계층 구조(layered architecture)입니다.
저 또한 처음 계층 구조로 개발을 시작하고 오랜 시간 동안 계층 구조로 개발을 해오면서 여러 장단점을 느꼈습니다.
가장 큰 장점은 구조가 단순하다는 것입니다. Controller, Service, Repository로 대표되는 큰 계층으로 나뉘어 개발자는 해당 계층에 맞게 클래스를 선언하여 데이터를 가공하고 다음 계층으로 넘겨주는 코드를 작성하면 됩니다. 이외에도 계층별 단위 테스트를 작성하기에 용이하다는 등의 장점이 있겠으나 최근에 느낀 것들은 대부분 단점이므로 생략하도록 하겠습니다.
제가 느낀 가장 큰 단점은 너비(breadth)에 대한 고려가 되지 않은 아키텍처라는 것입니다. 간단한 예시로 상품과 주문이라는 큰 도메인이 있고, 상품을 결제하고 주문 정보를 생성하는 기능과 주문을 취소하는 기능을 구현해야하는 상황이 있다고 가정합니다.
각 기능은 상품과 주문이라는 도메인에 걸쳐 있는 기능입니다. 상품을 결제하면 주문 정보를 생성해야하며, 주문을 취소하면 상품의 재고를 수정해야하기 때문입니다.
이런 도메인에 걸쳐 있는 기능을 개발할 때 유지보수성을 고려하게 되면 온전히 한 도메인에 속해있는 기능을 개발할 때보다 더 큰 노력을 기울여야 합니다. 순환 의존성 (Cyclic dependency)이 발생하거나 차후에 복잡한 요구사항을 만족해야 하는 상황이 오게 되면 코드 퀄리티가 낮아지기 때문입니다.
저는 이런 상황이 올 때 최선의 방향으로 개발을 하려 노력했지만 항상 드는 생각은 최선이 아닌 차선의 방법으로 가고 있다는 느낌을 받았습니다. 이것이 바로 제가 도메인 주도 개발 및 계층 구조가 아닌 다른 아키텍처에 대해서 공부하고자 하는 이유입니다.
물론 계층 구조가 아닌 다른 구조를 도입함으로써 제가 가진 고민을 해결할 것이라 생각하지 않습니다. 계층 구조 안에서 제가 직면한 문제들을 해결할 방법이 있다고 생각합니다.
하지만 그런 방법을 생각해내고 구현하기엔 저에게 통찰력과 지식이 부족하다고 생각합니다. 그래서 오랜 시간 잘 사용해왔던 계층 구조가 아닌, 다른 구조의 아키텍처와 개발 방법론을 접하면서 통찰력과 지식을 높이려고 합니다.
저는 새로운 라이브러리나 프레임워크, 프로그래밍 언어를 학습할 때는 공식 문서를 참고하고 이론을 학습할 때는 교재를 선호합니다. 아무래도 전자의 경우는 바로바로 적용할 수 있는 학습 방법이 효율적이고 후자의 경우는 여러 번 읽어봐야 완전히 이해가 되기 때문이지 않을까 싶습니다.
그래서 저는 도메인 주도 개발 시작하기 책을 시작으로 클린 아키텍처, 헥사고날 아키텍처 관련 교재를 구입하여 읽고 든 생각 및 후기를 작성하도록 하겠습니다.
여러분들도 앞으로 제가 작성할 게시글을 보고 많은 것을 얻어가시길 바라겠습니다 !
글을 읽어주셔서 감사합니다.