[Set] #7 - 모듈 내 세부 계층 잡기, 리소스 추가

[EunHee-Jeong]

👻 작업한 내용

• 모듈 내 세부 계층 잡기 (폴더링)
• 리소스 추가 및 생성 코드 작성

🎤 PR Point

• Presentation / Domain / Data 모듈 세부 계층 잡았습니다.
• Presentaion에만 샘플 파일 추가해놓았습니다.
• 추가한 리소스는 열거형으로 접근하여 사용하시면 되고, 추후 파일이 추가될 경우 해당 case를 확장하는 식으로 사용하시면 됩니다.

📸 스크린샷

구현 내용	스크린샷
어쩌고저쩌고	어쩌고저쩌고

📮 관련 이슈

• Resolved: [Add] 폴더 계층 세팅 및 리소스 추가 #7

[L-j-h-c]

계층 세팅, 리소스 추가하느라 고생 많으셨습니다..! 몇가지 제안이 있어요~~

1. 현재 디자인 관련 Resource들이 Presentation에 들어있는데, 제 생각에는 DSKit에 있는 것이 좀더 성격에 맞지 않나 싶습니다. Factory도 함꼐요!
2. Domain 내부의 Entities를 Model로 바꾸면 좋을 것 같습니다. 현재 네트워크 모듈이 분리되어 있기 때문에 네트워크 모듈에서 받아온 것들을 Entity로 넣고, Entity에서 toDomain 메서드를 만들어서 model로 만들어주는 식으로 하면 좋을 것 같아요!
3. Data 내부의 Repositories를 RepositoryImpl로, Domain 내부의 Interfae를 Repository로 바꾸는게 어떨까요? 근거는 Interface라는 네이밍이 모호하기 떄문입니다.

[EunHee-Jeong]

1. 반영하겠습니당

2. 저는 네트워크 모듈의 끝에서 도메인 모듈의 끝으로 온 것들(API)을 담는 곳이라는 의미로 Entities 라고 네이밍했는데요!
   의견 반영해서 아래 구조로 바꾸어보려고 하는데 어떤가요?

Domain
 |- UseCases
 |- Entities
      |- API (== from network)
      |- Model

• Interfaces는 제거
• Network 모듈에는 써드파티 프레임워크나 URLSession 모듈화 코드들이 들어가게 됨

3. 2번처럼 하면 인터페이스를 살려도 괜찮지 않을까요?! 도메인 레이어에서는 저장소의 인터페이스를 갖고, 데이터에서는 저장소를 갖는다는 의미가 명확해질 것 같습니다!!

[L-j-h-c]

넵넵 의견 반영 감사합니다~~!

2에 대해서는 찾아보니 Entity도 좋을 것 같다는 생각이 드네요! 그런데 API를 Domain에 폴더링하기가 애매한 것이, 본래 네트워크는 Data Layer에 포함되기 때문에 따로 분리된 상태여야 한다고 생각합니다. 그래서 Entity는 그대로 살리고, 네트워크 모듈에 포함되는 데이터를 받아올 모델은 DTO(Data transfer Object)라고 네이밍해야할 것 같네요 DTO, Entity

3에서 개인적으로 Interface라는 네이밍이 애매하다고 생각하는 이유는, 다른 객체지향 프로그래밍 언어(Java)들에서 Interface란 단어가 일반적인 의미를 가지고 있기 때문입니다. 한 프로젝트 내에는 수많은 인터페이스가 존재할 수 있는데, 어떤 것에 대한 인터페이스인지에 대한 의미를 나타내는 데에 한계가 있어 혼동을 줄 수 있을 것 같습니다. RepositoryInterface라고 한다면 또 괜찮을 것 같기도 해요!

[L-j-h-c]

고생하셨습니다!! 화이팅~