레이어드 아키텍처란 무엇인가: 핵심만 정리
레이어드 아키텍처를 presentation, application, domain, infrastructure 책임 기준으로 쉽게 정리합니다. 왜 계층을 나누는지, 흔한 오해는 무엇인지, 언제 layering이 ceremony가 되는지도 함께 봅니다.
레이어드 아키텍처를 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가 필요한지 분명한 판단 기준이 필요합니다.
상속보다 조합이 더 나은 순간은 분명합니다. 이 글에서는 객체지향 설계에서 조합을 고르는 기준을 변경 비용, 역할 재사용, 위임, 치환 가능성, 옵션 조합 관점으로 실무적으로 정리합니다.