직접 프로젝트를 개발해보면서 느낀 것인데, 흔히 말하는 ‘은총알은 없다’가 맞는 거 같다. 짧은 개발 지식으로 예시를 조금 들어보려고 한다. 일단 현재 백엔드 개발에 집중하고 있는 상태라서 백엔드를 예로 들면 좋을 거 같다.
백엔드 도메인
클린 아키텍처, 레이어드 아키텍처, 헥사고날 아키텍처 뭐 이런 건 정확하게 모르지만, 백엔드에는 도메인이라는 개념이 중요하다. 백엔드에서 도메인이란 내가 이해한 바로는 비즈니스 용어 혹은 자연스러운 일상 용어로 표현될 수 있는 무언가이다. 도메인 용어는 프론트엔드 개발자, 백엔드 개발자, 디자이너, 프로젝트 매니저, 기획자 등 상관없이 쓰일 수 있는 범용적인 용어인 것 같다.
네트워크 도메인, 수학 도메인 등 도메인이라는 용어에 여러 개념이 존재하지만, 여기서는 백엔드에서의 도메인 혹은 프로젝트에서 개발 대상이 되는 도메인을 말하는 거다.
백엔드 도메인 순수성
웬만하면 도메인은 순수성을 높이려고 노력하면 좋다. 순수성이 높으면 도메인은 되도록 기술적인 용어에 종속되지 않고, 순수 프로그래밍 언어로만 작성된다. 외부의 기술들과 독립적이게 되다 보니 유지보수가 쉬워진다. 기술이 바뀜에 따라 도메인의 용어를 바꾸지 않아도 되고, 도메인 메서드 등을 고치지 않아도 되기 때문이다. 추상화된 도메인을 설계, 기획하고, 인프라에 해당하는 외부 기술들이 이 추상화된 설계를 따르도록 하면 순수성을 유지하는 것이 가능하다. 이걸 어려운 말로 의존성 역전이라고 부르는 거 같다.
하지만, 도메인의 순수성을 지키기 위해서는 초기 구현에서 오버헤드가 생긴다. 외부 기술을 도메인으로 가지고 오기 위한 매퍼와 dto가 외부 대상마다 필요하고, 리포지토리 메서드를 구현하는 어댑터 등을 구현해야 하기 때문이다. 이러한 오버헤드는 속도감 있게 개발해야 하거나, 도메인 구현이 단순한 경우에는 오히려 개발 비용을 증가시킨다.
대기업 규모의 시스템이나 안정성이 극도로 필요한 물류, 은행 등의 시스템에서는 도메인의 순수성을 높이는 것이 좋지만, 규모가 작고, 프로젝트 초기에 빠르게 개발하려고 하는 스타트업이나 중소, 중견 기업에서는 도메인의 순수성을 낮아도 좋은 거 같다.
도메인에 대략적인 느낌을 구체화해가면서 느낀점
뭐 아직 프로젝트를 제대로 해본 적은 없고, lsgeun/ecommerce 프로젝트만 집중적으로 진행하는 중이지만, 여러 글들을 보고, gemini와 대화도 해보고, 혼자 깊은 사고도 해보면서, 도메인에 대한 대략적인 느낌? 개념?을 구체화해가면서 느낀점을 글로써 풀어봤다.