데이터를 많이 다루는 앱일수록 모델 탈중앙화를 적용한 도메인별로 모델을 분리하는 것이 지나치게 엔지니어링 측면이 강하다는 의견이 충분히 있을 수 있습니다. 예를 들어, 1️⃣ 백엔드에서 명세가 변경될 때 변경 사항을 모든 모델에 매핑해야 합니다. 2️⃣ 모든 모델에 매핑하는 작업을 수행하기 위해 코드를 두 배 이상으로 늘리고 있습니다. 🤔 이런 시나리오에서는 모델 탈중앙화의 장점은 보이지 않고 코드 중복만 보입니다. 💡 1️⃣과 같은 상황이 생기는 것을 방지하기 위해 모델 탈중앙화를 합니다! 백엔드 명세가 변경되면 API 모듈만 변경하면 됩니다. API 명세가 변경으로 인해 발생하면 API 모듈만 변경시키고 싶은 것이 모델 탈중앙화로 얻고 싶은 장점입니다. 만약 도메인별로 별도의 모델이 없으면 이 변경 사항이 UI 및 Persistance와 같은 다른 모듈로 연쇄적으로 영향을 미칩니다. 또한 변경의 영향을 받는 모든 모듈을 다시 컴파일하고 다시 배포해야 합니다. 이상적으로는 응집도 있는 한 모듈의 변경 사항이 다른 응집도 있는 모듈에 영향을 미치지 않아야 합니다(어렵습니다만🥲). 이것이 바로 모듈식 설계의 힘입니다👍 또한 모델 탈중앙화가 코드를 중복해서 작업하는 것처럼 보일 수 있습니다. 모델의 생김새가 매우 유사하기 때문입니다. 하지만 이들은 결코 동일하지 않습니다😱 RemoteFeedItem 은 백엔드에서 수신하는 모델을 나타내고 FeedItem은 우리 앱의 도메인 모델을 나타냅니다. 비슷하지만 다릅니다. 다르다는 이유로 다른 이유로 변경될 수 있습니다. 예를 들어, 앱에 새로운 기능을 추가하기 위해 백엔드 모델의 일부 속성의 이름을 바꾸거나 해당 모델이 표시되는 방식을 변경할 수 있습니다. 또한, 태그 지정, 저장, 즐겨찾기 등 백엔드에 의존하지 않는 일부 인앱 기능을 수용하기 위해 앱 모델이 변경될 수 있습니다. 또한 모델 탈중앙화를 통해 모듈을 개별적으로 개발, 유지 관리, 테스트 및 확장할 수 있습니다. 예를 들어, 앱에서 아무것도 변경하지 않고도 전체 API 사이드이펙트를 다른 백엔드(예: Firebase)로 교체할 수도 있습니다. 그러므로 앱을 외부 시스템과 분리하기 위해 도메인별 모델을 만드는 것이 좋습니다. 하지만 전체 시스템을 API 세부 정보와 연결할지는 엔지니어가 결정할 문제입니다. 선택의 문제입니다✅