클린 아키텍트니 뭐 XX아키텍쳐니
이런 형태에 집착하는 행태는 기술적으로 그게 반드시 맞는게 아니라
일반화된 언어와 규칙으로 소통하기 위한 약속임
클린 아키텍쳐를 선택하겠다
우리는 클린 아키텍쳐가 대강 어떤 구조를 띄워야하는지 이ㅐ를 함.
그게 바로 '낮은 비용의 커뮤니케이션 프로토콜'임
그러니까 새로운 팀원이 와도 형태를 유추하면 '아 유스케이스의 위치와 데이터 접근의 위치는 이 쯤에 있겠구나' 인지하는거고
근데 만약에 다른 팀원이 클린 아키텍쳐 선택이 힘들다면 그건 그 프로토콜 비용이 비싸다는 걸 의미해서 다른식으로 문서화해야겠지
중요한건 아키텍쳐는 나의 인지 총량과 팀을 위한 언어여야하지
반드시 무언가가 아님
중요한건 만들어서 납품한다는 행위지.
오개념: “클린 아키텍처는 단지 ‘낮은 비용의 커뮤니케이션 프로토콜’이다” → 오개념. 클린 아키텍처의 핵심 목적은 의존성 역전(Dependency Inversion)을 통한 비즈니스 로직의 독립성 확보이지, 단순히 커뮤니케이션 효율을 위한 약속이 아님. “클린 아키텍처의 형태에 집착하는 건 기술적으로 옳지 않다” → 부분 오개념. 형태(레이어링, 경계 등)는 구현 세부가 아니라 원칙을 실천하기 위한 구조적 표현으로, 일정 수준의 “형태적 일관성”은 기술적으로 의미 있음. “클린 아키텍처 선택이 힘들면 프로토콜 비용이 비싸다는 의미다” → 오개념. 선택이 어려운 이유는 팀의 이해도나 도메인 복잡성, 기존 코드베이스 제약 등 기술적·조직적 요인 때문이지, 단순히 ‘커뮤니케이션 비용’으로 환원할 수 없음.
왤케 아는척함 븅신아 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
나도 클린 아키텍처가 정답이 아니라는건 알고있음. 결국 프로젝트 규모나 기타 사항에 따라 취사선택 할 줄 알아야 한다는건 알고있지. 문제는 그것도 아는 사람이니 이번에는 이거쓸까 저거 쓸까 할 수 있으니 일단 해보려는거임.
ㅇㅇ 아니 너 말고 너야 당연히 이해하는데 저 위에 있는 한마리 있음