feature 영역은 AI가 매번 생성하더라도 앱 전반에 사용되는 공통 모듈은 일관성을 맞춰 재사용 가능하게 만드는 것이 바람직하다고 생각한다. 그 이유는 아래와 같다.
첫번째로 core는 여러 feature에서 공통적으로 사용된다. 이 때 일관성을 갖춰야한다.
두번째로 core는 여러 앱 사이에 달라져야하는 부분이 많지 않다. 세부적인 내용은 바뀌더라도 큰 틀은 바뀌지 않는다.
세번째로 개발자가 여러 앱을 수정하며 일관성을 가지고 작업할 수 있어 생산성이 높아진다.
다만, 이 문서를 작성한 작성자도 flutter 에 깊은 지식을 가지고 있지는 않기에, 설계가 잘못되었을 수도 있고, 시간 관계 상 여러 앱에 테스트를 해보지는 못했다. 지속적인 업데이트가 필요하고, 대대적인 수정이 필요할 수도 있다.
원래 담으려고 했던 타입 T 또는 Failure의 코드와 이유 둘 중 한가지를 가지게 된다.
이 Result 는 계층간 반복적인 exception throwing을 리턴타입 안에 담아 안정된 역할을 하도록 하였다.
.when 익스텐션은 Result가 성공인지 실패인지를 가르는 if 문과 타입 추론을 편리하게 해주는 메서드이다.
Result 기반 예외처리 시스템으로 바뀌면서 repository 에서는 매번 똑같은 Failure 들을 각 api 마다 만들고 있어야했다. 각 쿼리는 비즈니스 본질적인 메서드들을 try 로 감싸고, 매번 같은 Exception들을 catch 해서 적절한 Failure로 만들어야해서 코드가 길어지고 가독성은 떨어졌다. 이를 해결하기 위해 ResultWrapper를 만들었다.
ResultWrapper 의 역할 범위는 다음과 같다. 비동기 API 같은 요청에서 발생하는 exception을 모조리 catch 해서 적절한 형태의 AppErrorCode 가 담긴 Faiure로 변환해준다. 그리고 로깅한다.
화면이 터지지 않는다고 해서 이 Faiure로 변장한 예외들을 무시해서는 안된다. 특정요청에 대해 예상하지 못했던 부분에서 예외가 로깅된다면, 해당 Failure를 어떻게, 어디서 처리해줄지 고민해야한다.