Flutter 클린아키텍처를 공부하면서 생긴 의문점 ~ ing

클린아키텍처 이해했어

 

이번 글은 초보 개발자가 클린아키텍처를 공부하면서 만나는 의문점들과 그에 대해서 조그맣게나마 공부하고 정리한 내용이다.

앞으로도 의문점들이 추가 될때 추가적으로 작성할 예정이다.

 

이번에 새로운 프로젝트를 시작하기에 앞서해보고 싶은 내용들을 정해봤다.

- 클린아키텍처 사용하기

- 작게나마 테스트코드 적용하기

이렇게 세가지의 조건을 가지고 클린 아키텍처에 대해서 공부하던 중에 생긴 의문점들과 그에 해당하는 답변들을 정리해보려고 한다.

 

1. DTO ~ Mapper ~ Model 이 효율적인가?

일단 지금까지의 내가 해오던 방식은 Model만 정의해서 사용했다.

이렇게 사용한 방법은 아래와 같이 옵셔널 하게 미리 정의해 놓고 필요한 값만 꺼내서 쓰는 방식이었다.

class User {
	String? id;
    String? name;
    String? email;
    String? phone;
}

 

근데 클린아키텍처를 공부하면서 지금까지의 개념과는 다르게 작용한 부분이라고 생각된다.

DTO 가 서버에서 받아온 데이터

Mapper 를 통해서

Model 이 된다 라는 개념이였다.

 

그래서 클로드에게 질문해 보았다.

아래는 질문에 대한 답변이다.

클린 아키텍처에서 DTO와 Model을 나누는 접근법에 대한 질문이시군요.

DTO와 Model을 분리하는 대신 Model에서 optional 값으로 처리하는 것이 더 편할 수 있다는 생각은 이해가 됩니다. 실제로 많은 개발자들이 이런 방식도 고려합니다. 각 접근법의 장단점을 살펴보겠습니다:

DTO와 Model을 분리했을 때의 장점:

관심사 분리: 네트워크 데이터 구조(DTO)와 앱 내부 로직 데이터 구조(Model)가 명확히 분리됩니다. API 변경 대응: 서버 API가 변경되더라도 내부 Model은 변경할 필요가 없고 Mapper만 수정하면 됩니다. 테스트 용이성: 비즈니스 로직을 테스트할 때 서버 응답 구조와 독립적으로 테스트할 수 있습니다. 도메인 중심 설계: 앱의 비즈니스 요구사항에 맞는 Model 설계가 가능합니다.

단일 Model에 optional 값으로 처리할 때 장점:

코드 간결성: 추가적인 매핑 코드가 필요 없어 코드량이 줄어듭니다. 개발 속도: 빠른 개발이 가능하고 DTO-Model 간 매핑 오류가 발생하지 않습니다. 유지보수 단순화: 변경 시 한 곳만 수정하면 되어 동기화 문제가 없습니다.

실제로는 프로젝트의 규모와 요구사항에 따라 적절한 접근법을 선택하는 것이 중요합니다:

작은 프로젝트나 빠른 프로토타이핑에서는 단일 Model에 optional 값을 사용하는 것이 개발 속도와 간결성 측면에서 더 효율적일 수 있습니다. 대규모 프로젝트나 장기 유지보수가 필요한 앱에서는 DTO-Model 분리가 확장성과 유지보수 측면에서 더 유리할 수 있습니다.

결국 트레이드오프의 문제이며, 현재 개발 중인 앱의 상황과 팀의 선호도에 따라 결정하는 것이 좋습니다. 중요한 것은 일관된 접근법을 유지하는 것입니다.

 

결론적으로는 선호도 차이 이게 내 눈에는 가장 크게 보인다.

일단은 정석의 방식대로 구현하고자 했을 때는 DTO, Model 을 분리해서 사용하는 것이 맞다고 생각된다.

그리고 최초의 목표 설정에 결국 테스트 코드 작성도 포함되어있고 무엇보다 정석을 알아야 편리함도 안다고 생각된다.

그래서 더욱더 정석의 방식대로 공부하려고 한다.