클린 아키텍처 중 하나인 헥사고날 아키텍처를 찍먹하기 좋은 책 하나 추천합니다. 톰 홈버그의 만들면서 배우는 클린 아키텍처 입니다. 페이지 수도 200페이지가 안되어 쉽게 이해할 수 있습니다. 저도 이 책을 시작으로 클린 아키텍처를 도입 후 생산성과 유지보수 등 많은 도움이 됬습니다.
좋은 영상 감사합니다! 영상을 보면서 궁금한 점이 생겼습니다! 혹시 영상의 5:23 부분 그림에서 Domain 레이어에 use-case와 entity가 같이 있는데, clean architecture의 그림을 보면 application 레이어와 domain 레이어로 나눠져서 각각 use-case와 entity가 포함되어 있는데 use case는 애플리케이션 레이어에 포함되는 것이 맞는 건가요?? 아니면 domain 레이어에 포함되는게 맞는건가요??
안녕하세요! 좋은 질문 감사합니다! 위에서의 표현은 조금 더 이해하기 쉽게 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가지 요약이 생각을 딱 정리해주는 것 같네요! 감사합니다!
![[NHN FORWARD 22] 클린 아키텍처 애매한 부분 정해 드립니다.](http://i.ytimg.com/vi/g6Tg6_qpIVc/mqdefault.jpg)
![[마틴 파울러] 소프트웨어 아키텍처의 중요성 (한글 자막)](http://i.ytimg.com/vi/4E1BHTvhB7Y/mqdefault.jpg)
예시를 정말 적절하게 잘 들어주셔서 그런지 용어들이 쉽게 이해가 됬습니다. 덕분에 다른 자료 읽는데 도움이 많이 되었습니다.
댓글 감사합니다 :) 앞으로도 좋은 컨텐츠 만들어보겠습니다~! 😎
설명이 쉽고 좋네요
와 설명 자체가 정말 간결하고 쉽게 다가오네요 개념 자체에 주저앉은 적도 많은데 자신감 얻고갑니당
실제 적용할 때 폴더링이나 레이어를 나눴지만 막상 어떤 레이어로 구분할지 많이 헷갈리더라구요 ㅜ
오왕 ㅋㅋ 댓글이 하나도 안달려서 컨텐츠 망했나 했는데 ㅋㅋㅋㅋ 감사합니다!
실제 적용 사례와 더불어서 더 재밌는 주제들도 많아서 고건 하나씩 또 풀어가보도록 하겠습니다 ㅎㅎ
영상 잘봤습니다!
감사합니다~! ㅎㅎ
드디어 클린아키텍쳐가 뭔지 알았어요 감사합니다
그럼 이제 프로젝트에 적용 레쓰기릣!
클린 아키텍처 중 하나인 헥사고날 아키텍처를 찍먹하기 좋은 책 하나 추천합니다.
톰 홈버그의 만들면서 배우는 클린 아키텍처 입니다.
페이지 수도 200페이지가 안되어 쉽게 이해할 수 있습니다.
저도 이 책을 시작으로 클린 아키텍처를 도입 후 생산성과 유지보수 등 많은 도움이 됬습니다.
추천 감사합니다~! :)
좋은 영상 감사합니다!
영상을 보면서 궁금한 점이 생겼습니다!
혹시 영상의 5:23 부분 그림에서 Domain 레이어에 use-case와 entity가 같이 있는데, clean architecture의 그림을 보면 application 레이어와 domain 레이어로 나눠져서 각각 use-case와 entity가 포함되어 있는데 use case는 애플리케이션 레이어에 포함되는 것이 맞는 건가요?? 아니면 domain 레이어에 포함되는게 맞는건가요??
안녕하세요! 좋은 질문 감사합니다!
위에서의 표현은 조금 더 이해하기 쉽게 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가지 요약이 생각을 딱 정리해주는 것 같네요!
감사합니다!
대부분 mvvm을 오해하고 잘못쓰고있어요
"의미 없는 아키텍쳐의 사용은 중요하지 않다"
기술 습득에 게을러서도 안되지만, 기술에만 도취되어서도 안되죠 ㅎㅎ 😎