[Clean Architecture - Slog]
주요 목표
- Clean Architecture의 개념을 정리한다.
- Clean Architecture를 설들력있게 호소한다.
- Clean Architecture가 ASP.NET Core에 어떻게 적용되어 있는지 설명한다.
- Clean Architecture를 적용한 예제를 만들고 연구한다.
계획서
Robert C. Martin의 책 Clean Architecture, 인터넷 자료를 참고하여 개념을 정리한다.
장단점을 나열하고 왜 사용해야하는가, 개발자 현실과 상황에 빗대어 적용점을 나열한다. (+ 설문조사 연구)
1번의 정리한 개념을 MS Docs에서 어떻게 적용하고 나열하고 있는지 파악한다.
먼저 흔히 사용되고 있는 개념을 나열하고 앞으로 연구결과를 공유한다.
2022.07.05 시작합니다.
[시나리오 구성 중]
기름 시추 기계 : 회사
기름 : 자원, 자본, 프로그래머
자동차 : 투자한 자원으로 만들어 낸 수익 모델, 설계 도면
달성 거리 : 매출액, 프로그램 완성도
기름을 뽑아내는 기계가 매일 100L를 생산합니다.
우리는 자동차를 가지고 있으며 한정된 기름으로 가능한 멀리 달려가야합니다.
많이 갈수록 좋은 성과를 얻었다고 할 수 있습니다.
기름은 매일 100L로 자원이 한정된다고 했을 때
어떻게 해야 가능한 멀리나아 갈 수 있을까요?
연비 좋은 자동차를 개발해됩니다.
즉 엔진 효율을 높이고 공기저항에 효율적인 디자인이어야합니다.
현재 연비는 10km/ℓ 이며
연구개발에 투자 해 연비개선으로 20km/ℓ 를 달성합니다.
매일 1,000Km를 갈 수 있엇던것이 2,000Km 갈 수 있으며
100일이 지나면 100,000Km(10만 Km)가 차이 납니다.
반대로 가능한 멀리가는 것이 아니라 한정된 짧은 거리 3,000Km를 가야한다면
연구개발에 투자할바엔 3일간 그냥 달리면 되겠죠?
Clean Architecture는 설계에 있어서 초기 투자되는 비용이 크기 때문에
장기적으로는 좋으나 단기적인 소규모 프로젝트에는 맞지않습니다.
또 이용 가능한 자원에 제한을 받습니다.
Clean Architecture로 개발하는데 드는 초기 비용이 10이라고하고
회사 자본이 10이라면 수익 나기도 전에 파산하겠죠?
많은 회사들이 좋은 기획안이 있음에도 수익내기 힘든 것이 여기서 시작된다고 봅니다.
좋은 품질과 서비스를 보장할 수 있으면 수익을 낼 수 있을거라고 기대하지만,
실상 회사 자원으로는 높은 품질의 어떠한 것을 내기가 힘듭니다.
이점에 빗대어 봤을 때 Clean Architecture은 작은 규모의 회사에도 맞지 않습니다.
개인적으로 현실적으로 보았을 때 꾸준히 좋은 수익을 내는 모델이 있다면,
이 거 제대로 해보자라는 결심을 가지고 Clean Architecture로
재정비하는 것이 맞다고 생각합니다.
그러면 Clean Architecture는 사용되지 않느냐?라고 한다면
이미 많은 분들이 사용하고 있을 것 입니다. (IoC, DI 등 )
아니 그러면 이미 사용하고 있는데, 뭐 어떻게하라는 건가요?
=> Architecture를 사용하고 있으시지만 100% 완벽히 적용하고 있으신건 아닐 겁니다.
Architecture의 개념은 있지만 실질적인 존재가 없다고 판단됩니다.
다만 지금 현재 사용하는 Architecture보다 더 나는 Architecture가 있을것이고
현재 상황에 맞게 Architecture를 적용해보자 입니다.
단순히 자원이 많으니까 무조건 Clean Architecture
'자원이 부족하니가 그냥 코딩’이 아니라 현재 상황에 맞게
필요한 만큼 Architecture를 적용하자가 주 목표입니다.
Clean Architecture란
한국말로 하면 건축학이라는 뜻으로 좋은 설계 도면을 가지고
소스 코딩을 하자라고 보시면 될것 같습니다.
좋은 설계도면이 있으면 무엇이 좋나요?
=> Clean Architecture은 최소의 비용으로 프로그래머의 생산성은 최대화하는 것 입니다.
즉 효율적인 생산이라고 보시면 되겠죠.
생산성의 판단하는 척도는: 쉬운 개발 - 배포 - 운영 - 유지보수 등이 되겠네요.
그리고 가장 중요하게 생각하는 것이 View에 관련된 의존성입니다.
똑같이 동작하는 프로그램인데 iOS, Android, MacOS, Window 따로따로 개발한다면 들어가는 자원이 많겠죠?
Clean Architecture에서는 전혀 다른 View 가진다면 View 바꿔 끼울 수 있어야 한다고 합니다.
(핵심 소스 1개와 4개의 View로 플랫폼 4곳에서 서비스 할 수 있다면 얼마나 좋을까요?)
좀더 자세하게 Clean Architecture 구조에 대해 말씀 드리겠습니다.
Credit: 도서출판 인사이트
각각의 원으로 분활되어 있으며 중심원으로 갈수록 고수준, 외각으로 갈수록 저수준이라고 표현하겠습니다.
의존성 규칙에 의해 의존성은 외부에서 안으로, 저수준에서 고수준으로 흘러갑니다.
즉 웹은 컨트롤, 유스케이스, 엔티티 등에 대해 알고 의존성을 가질수 있지만
그 어느것도 웹에 대해 의존성을 가지는 객체가 없어야하며
Core(유스케이스, 엔티티)는 외부에 의존하지 않아야합니다
이와 같은 기반으로 ASP.NET Core는 Core, Infrastructure, Wep으로 나뉩니다. + Test, 테스트 환경(Docker 등…)
Core : 가장 안쪽 원으로 엔티티, 유스케이스의 영역이 됩니다. (Business/ Appliction Model)
Infrastructure : 초록색 영역입니다. (Data Access Logic)
Web: 하늘색 영억으로 웹 View이죠. (Presentation Logic)
그래서 이렇게 나뉘는데 해당 요소는 어떻게되냐?라고 하신다면
[MS Docs]
이 것을 참조 부탁드립니다. (현재 정리해둔 메모가 지금 없네요, 쓴 내용 고대로 다시 쓰는 중 입니다…)
2022.07.05 종료합니다.