iOS앱 개발🍎: 의미 있는 데이터 모델1

‘의미 있는’ 개념을 모델로 표현하기는 것응 쉽지 않습니다. 요구 사항 내에서 그다지 중요하지 않은 모델은 의미보다는 표현에 좀 더 치중하는 것이 올바를 수 있습니다. 하지만 ‘의미 있는’ 모델은 ‘도메인 개념을 1️⃣간단하고 2️⃣일관성 있게 표현해야 합니다.’ 이번 글을 시작으로 ‘의미 있는’ 모델을 만들려면 어떤 부분을 고려하면 좋을지 몇 번에 걸쳐 나눠보고자 합니다. 첫 번째로, 모듈의 경계를 넘어 모델을 공유할 때 생길 수 있는 문제점에 대해서 말해보고자 합니다. 두 개의 모듈이 하나의 모델을 공유할 때, 하나의 모듈(예: API)에는 필요하지만 다른 모듈(예: UI, Persistance)에는 필요하지 않은 동작(메서드)과 상태(속성)임에도 불구하고 하나의 모듈에서 사용하기 때문에 무작정 추가하기 쉽습니다. 비즈니스상으로 큰 문제가 발생하지 않았으면 하지만, 이 경우 모델의 크기가 커지고(간단하지 않고), 모델은 일관성을 잃기 시작합니다. 작은 단일 모델일지라도 객체, 모듈, Layer에 따라 다른 형태로 표현이 필요할 수 있습니다. 여러 모듈에서 단일 모델을 사용하면, 복잡하고 유지 관리 비용이 많이 들며 사용하기 어려운 코드가 될 수 있습니다. 따라서, 객체, 모듈과 Layer를 넘나들며 모델을 공유하고 전달하는 대신에 객체, 모듈과 Layer마다 별도의 모델, 데이터 전송 표현(TransferObjects 또는 DTO라고도 함)을 사용하는 것을 고려해야 합니다. 💡 별도의 모델 표현을 만들면 코드를 간결하게 유지하고 개발, 사용 및 유지 관리를 쉽게 할 수 있습니다. 이것은 ‘모델 탈중앙화’라고 말합니다. 처음에는 별도의 표현이긴 하지만 약간만 다른 비슷한 모델처럼 보일 수 있지만, 시간이 지남에 따라 서로 다른 이유로 변경되는 경우가 많습니다. 모델이 달라지기 시작하면 시스템이 일관성 없는 상태가 되지 않도록 개념을 분리할 준비를 하는 것이 중요합니다. 또한 팀원들은 각 모델의 컨텍스트에 대한 공통된/공유된 관점을 가지고 일관성을 유지하기 위해 노력해야 합니다. ⚠️ 모델 탈중앙화를 어떤 상황에서 접목을 시켜야 좋은지에 대한 상황이 분명히 존재하기 때문에 모든 상황에서 필요로 하지는 않습니다. 더욱이 괜히 이 부분을 신경 쓰다간 직관적이지 않은 코드가 될 수 있고, 추상화에 신경을 쓰다 보면 데이터 모델을 여러 가지로 표현하는 것은 추상화를 해칠 수 있습니다. 또한 개념을 너무 많이 분리하는 설계도 주의해야 합니다. 그렇지 않으면 시스템의 복잡성이 커지고 통합 비용이 증가하며 팀 간의 의사소통이 어려워지고 경계 내의 상관관계를 명확하게 파악할 수 없게 됩니다. ✅ 팀이 통합 모델을 프로젝트에 유지하기로 하든 그렇지 않든, 모델을 잘 만들고 사용하기 쉽게 유지하려면 의사소통이 필수입니다. 모든 소프트웨어는 각기 다른 속도와 이유로 진화하기 때문에 모듈을 재구성할 시기와 방법을 찾으려면 현재 설계, 도메인을 새로운 요구사항으로 리팩터링 해야 합니다. 건강하고 지속할 수 있는 코드 베이스를 위해 모듈 리팩터링 작업을 최소화할 방법을 늘 고민하는 개발자가 됩시다!