클린 아키텍처는 왜 어렵게 느껴질까: 계층보다 의존 방향이 핵심인 이유
클린 아키텍처가 왜 어렵게 느껴지는지, 계층보다 의존 방향이 왜 핵심인지, 그리고 무엇을 먼저 분리해야 하는지 실무 기준으로 정리합니다.
클린 아키텍처가 왜 어렵게 느껴지는지, 계층보다 의존 방향이 왜 핵심인지, 그리고 무엇을 먼저 분리해야 하는지 실무 기준으로 정리합니다.
레이어드 아키텍처를 presentation, application, domain, infrastructure 책임 기준으로 쉽게 정리합니다. 왜 계층을 나누는지, 흔한 오해는 무엇인지, 언제 layering이 ceremony가 되는지도 함께 봅니다.
안드로이드 클린 아키텍처를 작은 앱에도 넣어야 할지 고민될 때, 앱 규모와 팀 규모, UseCase·Repository·Mapper의 trade-off를 기준으로 현실적인 판단 방법을 정리합니다.
의존성 주입을 프레임워크 기능으로만 배우면 DI, DI 컨테이너, 서비스 로케이터가 쉽게 섞입니다. 이 글에서는 객체 생성과 의존성 전달을 분리하는 관점으로 DI의 핵심, 테스트 이점, 과설계 경계까지 실무적으로 정리합니다.
인터페이스 분리 원칙(ISP)을 슬로건처럼 외우면 실무에서 잘 안 보입니다. 이 글에서는 큰 인터페이스가 왜 변경 비용과 테스트 비용을 키우는지, 언제 역할별 계약으로 나누는 것이 좋은지 실전 기준으로 정리합니다.
코틀린에서는 data class copy() 덕분에 Prototype 패턴을 가볍게 쓸 수 있습니다. 하지만 copy()는 shallow copy이므로, mutable list나 nested object가 섞이면 언제 deep copy가 필요한지 분명한 판단 기준이 필요합니다.