제가 첫 프로젝트인 퍼디를 개발하면서 고민했던 도메인 설계에 대한 내용을 공유하고자합니다.
퍼디는 전문가 기반 질의응답 서비스입니다.
프로젝트 설명은 여기에서 확인할 수 있습니다.
AS-IS
프로젝트 초기 단계에서 “퍼디”의 핵심 기능 중 하나인 “전문가” 기능에 대해 고민하게 되었습니다. “전문가”는 일반 사용자와 다르게 특정 조건을 만족한 사용자만이 등록할 수 있는 기능으로, 자신의 전문성을 바탕으로 다른 사용자들의 질문에 답변을 제공하는 역할을 합니다.
이를 표현하기 위한 초기 도메인 모델 설계는 “전문가”를 사용자 도메인 내의 추가적인 정보, 즉 일종의 부가적인 속성으로 생각했습니다.
즉, 기본적으로 모든 사용자는 “전문가”가 될 가능성을 가지고 있으므로, 그에 따른 전문가 정보를 포함하는 사용자 테이블을 생성하는 것이 자연스러워 보였습니다.
그러나, 이렇게 설계할 경우 아래와 같은 몇 가지 문제점이 발생할 수 있음을 인지하게 되었습니다
데이터 중복: 사용자가 전문가로 등록되지 않을 경우, 해당 사용자의 전문가 정보 필드는 빈 값으로 남게 됩니다. 이런 빈 값들이 데이터베이스에 계속 쌓이게 되면, 공간을 차지하며 DB의 성능을 저하시키는 원인이 될 수 있습니다.
- 확장성 문제: 사용자와 전문가의 정보가 하나의 도메인에 모두 포함되어 있을 경우, 전문가 기능을 확장하거나 변경할 때마다 사용자 도메인을 함께 수정해야 합니다. 이는 유지보수의 어려움을 초래하며, 결국에는 시스템의 유연성을 저하시킬 수 있습니다.
- 단일 책임 원칙 위반: 유저 도메인이 전문가 정보까지 담당하는 것은 객체지향 설계 원칙 중 하나인 단일 책임 원칙에 어긋난다고 판단했습니다. 하나의 클래스는 하나의 책임만을 가져야 하지만, 이 경우 사용자 클래스는 자신의 기본 정보 뿐 아니라 전문가 정보까지 관리해야 했습니다.
이러한 문제점들을 생각해봤을때, 보다 효율적이고 확장성 있는 도메인 설계는 무엇일까에 대해 알아보게 되었습니다.
도메인 설계할 때의 고려했던 점
제가 생각했을때 도메인을 설계할 때 고려할만한 점은 아래와 같이 정리할 수 있었습니다.
도메인 간 결합을 최소화하기: 도메인 간 결합이 강하면, 한 도메인의 변경이 다른 도메인에 영향을 미칠 수 있습니다. 이는 시스템의 유지 보수를 어렵게 만들고, 예상치 못한 버그를 유발할 수 있다고 생각했습니다. 따라서, 각 도메인이 가능한 한 독립적으로 운영될 수 있도록 설계하는 것이 중요하다고 생각했습니다.
도메인 자체의 복잡도를 최대한 낮추기: 도메인의 복잡도가 높을수록 해당 도메인의 로직이 복잡해지고 이해하기 어려워집니다. 이는 코드의 가독성을 저하시키고, 버그 발생 가능성을 높일 수 있습니다. 따라서, 각 도메인의 복잡도를 최소화하는 것이 중요하다고 생각했습니다.
추후 확장성 고려하기: 서비스의 요구사항이 변경되거나 새로운 기능이 추가될 가능성을 항상 염두에 두고 도메인 모델을 설계하는 것이 중요하다고 생각했습니다. 이는 코드의 재사용성을 높이고, 필요에 따라 쉽게 기능을 추가하거나 수정할 수 있도록 하기 위함입니다.
TO-BE
그러므로, 이러한 문제점들을 해결하기 위해, 저는 결국 ‘전문가’ 도메인을 ‘유저’ 도메인과 분리하여 별도의 테이블로 관리하기로 결정했습니다.
이렇게 하면, 전문가 정보는 해당되는 유저만을 대상으로 관리되므로 데이터 중복 문제를 해결할 수 있습니다.
또한, 전문가 기능의 확장이 필요할 때마다 ‘유저’ 도메인을 수정하지 않아도 되므로 확장성이 향상됩니다.
그리고 ‘유저’ 도메인과 ‘전문가’ 도메인의 관심사가 분리되므로 각 도메인이 자신의 책임에 집중할 수 있습니다.
이렇게 도메인 설계를 통해 각 도메인의 결합을 최소화하고 도메인의 복잡도를 줄이며, 확장성을 고려한 설계를 수행했습니다.
이러한 과정을 통해 저는 도메인 설계의 중요성을 더욱 깊게 이해하게 되었습니다.
비즈니스 요구 사항이 변경되거나 새로운 기능이 추가될 때마다 기존 로직이나 테이블 구조를 크게 변경하지 않고도 구현할 수 있었습니다.
TO-DO
이번 프로젝트를 진행하면서, 도메인 설계에 대해 더 많은 시간을 투자한다면, 개발 과정에서 설계를 변경할 일이 없었을 수도 있겠다는 생각을 계속 했습니다.
도메인 주도 설계에 대해 더 관심을 갖게 되고 앞으로는 프로젝트를 진행할 때 도메인을 설계하는 것에 더 시간을 투자해야겠다는 생각이 들었습니다.