아키텍처를 공부하며 겪었던 성장통

 많은 개발자들은 개발을 시작하고 성장하면서 아키텍처에 대해 여러 방면으로 고민하고 나만의 방법을 찾아 나가기 시작합니다.

 

 저는 이런 성장 과정에서 여러 성장통을 겪었는데 그때 느꼈던 점을 정리해보려고 합니다!

 

 아키텍처를 처음 공부하고 배워나갈때 정답은 없지만 최소한 베스트는 있다는 생각으로 접근을 했었습니다. 이런 접근법은 지금 생각해보면 좋은 접근법은 아닌 것 같지만 그래도 저한테는 빠르게 나의 아키텍처를 찾는데는 도움을 주었습니다. 이런 아키텍처의 접근방식을 통해 다른 팀은 어떻게 아키텍처를 쌓아나가는지 그리고 DDD와 같은 설계 철학은 어떤 이야기를 하고 있는지 깊게 고민하고 공부하는 계기가 되게 해주었습니다.

 

 이 과정에서 겪은 성장통은 결국 아키텍처는 정답도 없고 베스트도 없다는 생각이였습니다. 우리가 아키텍처를 설계할 때에는 두 가지 관점으로 접근이 가능합니다. 전략적으로 접근하는 방법과 전술적으로 접근하는 방법입니다. DDD 설계 전략에서 나오는 말이지만 조금 더 멀리서 비즈니스관점으로 접근하는 전략적 방법과 각 독립된 도메인 내의 소규모 그룹을 기술적으로 탐구하는 전술적 방법을 의미합니다.

 

 여기서 우리는 어플리케이션이 지속적으로 커짐에 따라 아키텍처도 지속적으로 도메인에 적합하게 변경되어야 한다는 점을 이해하고 받아들여야합니다.

 

 간단한 예시를 들어본다면 어플리케이션의 크기가 작을때에는 JPA Entity와 Domain Model을 동일시 하고 개발할 때 더 효율적이고 확장 가능한 구조를 만들어 낼 수 있다면 도메인이 뚱뚱해지고 여러 작은 단위로 분산될때는 오히려 Entity와 Domain Model을 분해하고 DDD를 도입하면서 UseCase와 같은 별도의 묶음 레이어를 활용하는 것이 효율적으로 변할 수 있습니다.

 계속 DDD 책이야기를 하게 되지만 (최근에 다시 읽었기때문에 뽕뽑아야합니다..) DDD 책에서도 유연한 설계 방식과 본인의 방법이 정답이 아니라는 뉘양스를 곧곧에 풍기고 있습니다. 이런 관점에서 우리도 항상 내가 정답이라는 생각을 버리고 상황에 맞는 최적화된 방법을 찾아야하지 않을까 생각이 듭니다.