최근 아키텍처와 테스트의 관계에 대해 깊이 고민하게 되었다. 특히 "테스트하기 쉬운 코드가 곧 잘 짜여진 아키텍처"라는 말이 계속 머릿속을 맴돌았다. 이를 통해 깨달은 점들을 정리해보려 한다.
아키텍처란 무엇인가?
아키텍처는 단순한 설계 도구가 아니다. 비즈니스 문제를 해결하기 위해 준수해야 하는 제약을 넣는 과정이라고 생각한다. 이는 테스트 코드가 일종의 규약으로 작용한다는 점과 맥을 같이 한다. 중요한 건 아키텍처를 도입할 때는 반드시 그 이유에 대한 구성원들의 공감이 필요하다는 점이다. 공감 없는 아키텍처는 그저 장애물일 뿐이니까.
아키텍트의 진정한 목적
아키텍처를 다루는 아키텍트의 주요 목적은 결국 인적 자원의 절감이다. 이를 위해서는 다음과 같은 요소들이 필수적이다:
- 동시 작업이 가능한 구조
- 명확한 관심사의 분리
- 경계의 구분 (특히 의존성 역전을 통한)
의존성 역전 - 경계를 긋는 예술
의존성 역전이 왜 중요한지 최근에야 제대로 이해하게 되었다. 내가 DDD를 학습하며 작성했던 코드가 좋은 예시다. Input port(interface)를 상위 계층에 두고, 실제 구현체는 이를 따르게 만드는 구조. 이를 통해 Output Adapter 계층이 의존성을 관리하고 주요 비즈니스 로직을 처리하게 된다.
레이어드 vs 핵사고날 아키텍처
레이어드 아키텍처를 사용하면서 느꼈던 가장 큰 문제는 DB 위주의 사고에 갇히게 된다는 점이다. JPA 같은 외부 라이브러리에 종속되어 사고하게 되고, Service 레이어가 비대해지는 건 덤이었다.
반면 핵사고날 아키텍처는 상향식 접근이 자연스럽다. Domain 개발을 시작으로 Service layer, 그리고 input/output port를 거쳐 외부 연동 layer로 발전해간다. 외부 라이브러리에 종속적으로 Service를 작성한다는 건 애초에 잘못된 접근이었다는 걸 깨달았다.
도메인 모델의 순수성
"도메인 모델만큼은 순수해야 한다." 이 말에 전적으로 동의한다. Domain Entity와 JPA Entity의 분리 문제도 여기서 시작된다. 분리하면 구성이 복잡해질 수 있지만, 도메인이 DB에 종속되는 것을 막을 수 있다. 결국 이는 원칙과 편의성 사이의 균형 잡기다.
마치며
아키텍처는 고정된 것이 아니라 언제든 변화할 수 있다. 중요한 건 본질을 지키면서 실용적인 선택을 하는 것이다. "DB를 바꾼다고 계산 로직이 변경되면 안 된다"라는 말처럼, 프레임워크나 DB가 변경되어도 도메인은 그대로 이식할 수 있어야 한다. 이것이 바로 Test, DDD, OOP가 강조되는 근본적인 이유가 아닐까.
테스트와 아키텍처의 상관관계에 대한 고찰
최근 아키텍처와 테스트의 관계에 대해 깊이 고민하게 되었다. 특히 "테스트하기 쉬운 코드가 곧 잘 짜여진 아키텍처"라는 말이 계속 머릿속을 맴돌았다. 이를 통해 깨달은 점들을 정리해보려 한다.
아키텍처란 무엇인가?
아키텍처는 단순한 설계 도구가 아니다. 비즈니스 문제를 해결하기 위해 준수해야 하는 제약을 넣는 과정이라고 생각한다. 이는 테스트 코드가 일종의 규약으로 작용한다는 점과 맥을 같이 한다. 중요한 건 아키텍처를 도입할 때는 반드시 그 이유에 대한 구성원들의 공감이 필요하다는 점이다. 공감 없는 아키텍처는 그저 장애물일 뿐이니까.
아키텍트의 진정한 목적
아키텍처를 다루는 아키텍트의 주요 목적은 결국 인적 자원의 절감이다. 이를 위해서는 다음과 같은 요소들이 필수적이다:
- 동시 작업이 가능한 구조
- 명확한 관심사의 분리
- 경계의 구분 (특히 의존성 역전을 통한)
의존성 역전 - 경계를 긋는 예술
의존성 역전이 왜 중요한지 최근에야 제대로 이해하게 되었다. 내가 DDD를 학습하며 작성했던 코드가 좋은 예시다. Input port(interface)를 상위 계층에 두고, 실제 구현체는 이를 따르게 만드는 구조. 이를 통해 Output Adapter 계층이 의존성을 관리하고 주요 비즈니스 로직을 처리하게 된다.
레이어드 vs 핵사고날 아키텍처
레이어드 아키텍처를 사용하면서 느꼈던 가장 큰 문제는 DB 위주의 사고에 갇히게 된다는 점이다. JPA 같은 외부 라이브러리에 종속되어 사고하게 되고, Service 레이어가 비대해지는 건 덤이었다.
반면 핵사고날 아키텍처는 상향식 접근이 자연스럽다. Domain 개발을 시작으로 Service layer, 그리고 input/output port를 거쳐 외부 연동 layer로 발전해간다. 외부 라이브러리에 종속적으로 Service를 작성한다는 건 애초에 잘못된 접근이었다는 걸 깨달았다.
도메인 모델의 순수성
"도메인 모델만큼은 순수해야 한다." 이 말에 전적으로 동의한다. Domain Entity와 JPA Entity의 분리 문제도 여기서 시작된다. 분리하면 구성이 복잡해질 수 있지만, 도메인이 DB에 종속되는 것을 막을 수 있다. 결국 이는 원칙과 편의성 사이의 균형 잡기다.
마치며
아키텍처는 고정된 것이 아니라 언제든 변화할 수 있다. 중요한 건 본질을 지키면서 실용적인 선택을 하는 것이다. "DB를 바꾼다고 계산 로직이 변경되면 안 된다"라는 말처럼, 프레임워크나 DB가 변경되어도 도메인은 그대로 이식할 수 있어야 한다. 이것이 바로 Test, DDD, OOP가 강조되는 근본적인 이유가 아닐까.
