Clean Architecture 도대체 왜 쓰는거죠? | feat. MVC, MVVM, 클린아키텍쳐 | 주니어 개발자 꿀팁 

댓글 감사합니다 :) 앞으로도 좋은 컨텐츠 만들어보겠습니다~! 😎

감사합니다~! ㅎㅎ

오왕 ㅋㅋ 댓글이 하나도 안달려서 컨텐츠 망했나 했는데 ㅋㅋㅋㅋ 감사합니다! 실제 적용 사례와 더불어서 더 재밌는 주제들도 많아서 고건 하나씩 또 풀어가보도록 하겠습니다 ㅎㅎ

그럼 이제 프로젝트에 적용 레쓰기릣!

추천 감사합니다~! :)

안녕하세요! 좋은 질문 감사합니다! 위에서의 표현은 조금 더 이해하기 쉽게 Domain안에 DomainLayer와 ApplicationLayer를 같이 넣었습니다. 하지만 요거슨 크게 중요한 부분이 아니라서 추가로 답변을 적습니다 ㅎㅎ ApplicationLayer 에 위치한다는 것은 DomainLayer보다 변하지 않는 부분들을 의미합니다. ApplicationLayer는 앱 전체를 아우르는 룰, DomainLayer 는 해당 Framework에서의 룰이라고 이해하시면 좋습니다. 즉, UseCase는 Framework의 변화에 따라 변경이 될 수 있기 때문에 DomainLayer에 있는 편이 맞다고 생각합니다. 그렇다면 Entity는 반드시 ApplicationLayer에 있어야 하냐라고 물어보신다면, 저는 아니라고 생각합니다. DomainLayer 안에 좀 더 변하지 않는 영역인 EntityLayer를 만들수도 있죠. (팀 구성원들의 합의만 있다면요!) CleanArchitecture는 일종의 유지보수를 위한 코드 레시피라고 보시면 될 것 같습니다. 레시피대로 했을 때는 맛이 보장되지만, 가끔은 지나치게 번거롭기도 하죠. 현재의 상황과 팀내의 합의에서 좋은 지침이 되긴 하지만 반드시 따라야하는 정답은 아니죠! 이 관점에서 06:15 부분의 그림을 보여드린 것이었습니다 ㅎㅎ 우리가 조금 더 집중해야하는 것은 1. 내가 만드는 코드가 쉽게 변경이 가능한 영역에 위치해있는가 쉽게 변하지 않는 영역에 위치해야하는가? 2. 변하는 영역은 변하지 않는 영역을 알아야하지만, 변하지 않는 영역은 변하는 영역을 몰라야한다. 3. 변하는 영역에 대한 결정은 최대한 미룬다. 입니다. 이 3가지 원칙에 대해서 집중하신다면 더 좋은 코드를 생산하는데에 도움이 되실 것이라 생각합니다! ㅎㅎ

​@@boiledDeveloper 헉! 좋은 답변 감사합니다 ㅎㅎ 1. 내가 만드는 코드가 쉽게 변경이 가능한 영역에 위치해있는가 쉽게 변하지 않는 영역에 위치해야하는가? 2. 변하는 영역은 변하지 않는 영역을 알아야하지만, 변하지 않는 영역은 변하는 영역을 몰라야한다. 3. 변하는 영역에 대한 결정은 최대한 미룬다. 이 3가지 요약이 생각을 딱 정리해주는 것 같네요! 감사합니다!

개인적인 의견으로는 프로덕트 개발자가 지향해야하는 목표는 결국 고객(이는 내부 고객 일 수도 있습니다)에게 빠르고 안정적으로 프로덕트를 제공하는 것 이라고 생각합니다. 그리고 이를 위해 달성해야하는 골들(테스트, 확장성 등)을 쉽게 달성하게 만들어주는 일종의 템플릿이 클린 아키텍쳐 라고 보시면 될 듯 합니다!

@@boiledDeveloper 오 필연적인 존재이군요.. 어찌됐든 빠르개 다음 영상도 부탁드립니다.. 빠른 영상 업로드를 지향해주시면 감사하겠습니다..

최대한 빠른 업로드를 지향하긴 하지만.. 현생도 살아야하다보니.. ㅎㅎ 쬐끔 천천히 올라오더라도 양해부탁드림다 🙏

기술 습득에 게을러서도 안되지만, 기술에만 도취되어서도 안되죠 ㅎㅎ 😎