Files

T

DongHyeonka d71669eb59 fix: 하네스 제거 및 keycloak 문서 보강

2026-07-25 12:53:13 +09:00

9.4 KiB

Raw Permalink Blame History

title, source_type, url, archive_url, status, confidence, tags, related_branches, related_projects, created, last_reviewed

title

source_type

url

archive_url

status

confidence

Screaming Architecture (Uncle Bob)

Layer: raw/official-docs/ — Robert C. Martin (Uncle Bob) "Screaming Architecture" (cleancoder.com 블로그, 2011-09-30) verbatim 발췌. ca-tmpl 의 feature-first 결정 (대안 1, 채택 baseline) 의 이론적 출처.

Parent / 활용 branch (필수)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-architecture-enforcement-rules	패키지 최상위가 "use case / feature 이름" 으로 시작해야 한다는 ArchUnit 룰의 이론 근거
raw/branch-notes/feature-skeleton-package-blueprint-contract	`features/{featureName}/{presentation,application,domain,infrastructure}` blueprint 의 "feature 최상위" 분할 정당화
raw/branch-notes/feature-domain-feature-onboarding-contract	신규 기능 추가 시 framework 가 아닌 use case 로 패키지 명명하는 가이드
raw/branch-notes/feature-domain-modeling-guardrails	"architecture should tell about the system, not frameworks" — domain 이 framework annotation 으로 오염되지 않게 하는 원칙 근거

컨텍스트 / 왜 저장했는지

ca-tmpl의 feature-first 결정(대안 1, 채택 baseline)에 대한 이론적 근거. Uncle Bob이 제시한 "use case 중심으로 패키지를 잘라야 한다"는 주장은 Package-by-Feature의 정신적 뿌리이며, ca-tmpl이 features/{featureName} 단위로 자르는 이유의 1차 출처.

출처 / Source

원본 URL: https://blog.cleancoder.com/uncle-bob/2011/09/30/Screaming-Architecture.html
아카이브 URL: (미확보)
저자/조직: Robert C. Martin (Uncle Bob)
발행일: 2011-09-30
후속 정리: 동저자의 Clean Architecture (2017) 21장 "Screaming Architecture"
마지막 확인일: 2026-05-27

핵심 인용 / Key quotes (verbatim)

[§Opening question] "So what does the architecture of your application scream?"

[§Architecture vs framework] "Architectures are not (or should not) be about frameworks."

[§Deferred decisions] "A good software architecture allows decisions about frameworks, databases, web-servers...to be deferred and delayed."

[§Web as delivery] "The Web is a delivery mechanism, and your application architecture should treat it as such."

[§Reader perspective] "Your architectures should tell readers about the system, not about the frameworks."

[§Framework relationship] "Frameworks are tools to be used, not architectures to be conformed to."

[§Caution] "View it skeptically. Yes, it might help, but at what cost."

[§Building analogy] (요약) house plan 은 layout 만 봐도 "house" 임이 드러남 (foyer/living room/kitchen). library 는 grand entrance/check-out area/gallery shelves 로 "library" 임이 드러남. 소프트웨어도 동일하게 healthcare/accounting 등 시스템 목적이 드러나야 하며 Rails/Spring/Hibernate 같은 framework 가 드러나면 안 됨.

[§Ivar Jacobson 인용] "software architectures are structures that support the use cases of the system."

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
SCREAM-C1	좋은 소프트웨어 아키텍처는 framework 가 아니라 시스템의 use case / 도메인을 외부로 드러내야 한다	[§Opening] "what does the architecture of your application scream?" + [§Architecture vs framework] "Architectures are not (or should not) be about frameworks." + [§Reader perspective] "Your architectures should tell readers about the system, not about the frameworks."	`engineering-blog`	비즈니스 도메인이 명확한 시스템	"framework 사용 자체가 금지" 라는 뜻은 아님 — framework 는 도구로 사용 가능, 단지 architecture 의 정체성으로 두면 안 됨
SCREAM-C2	좋은 아키텍처는 framework/DB/web server 같은 환경 결정을 deferred and delayed 할 수 있어야 한다	[§Deferred decisions] "A good software architecture allows decisions about frameworks, databases, web-servers...to be deferred and delayed."	`engineering-blog`	장수 lifecycle 시스템	"환경 결정을 영원히 안 한다" 가 아니라 "초기에 못 박지 않는다" 의 의미 — 본 글에서 정확한 deferment 시점 기준 미제시
SCREAM-C3	Web 은 delivery mechanism 이며 application architecture 의 일부가 아니다	[§Web as delivery] "The Web is a delivery mechanism, and your application architecture should treat it as such."	`engineering-blog`	web/UI 가 있는 시스템	REST controller / HTTP 라우팅을 작성하지 말라는 뜻은 아님 — 단지 domain core 가 HTTP 에 의존하지 말아야 한다는 원칙
SCREAM-C4	Framework 는 conform 해야 할 architecture 가 아니라 use 할 도구다 — 비용 의식적으로 채택해야 함	[§Framework relationship] "Frameworks are tools to be used, not architectures to be conformed to." + [§Caution] "View it skeptically. Yes, it might help, but at what cost."	`engineering-blog`	Spring/Rails/Django 등 opinionated framework 채택 결정	framework 자체를 거부해야 한다는 뜻 아님 — trade-off 평가가 의무
SCREAM-C5	(Ivar Jacobson 인용) 소프트웨어 아키텍처는 시스템의 use case 를 지원하는 구조다	[§Jacobson 인용] "software architectures are structures that support the use cases of the system."	`engineering-blog` (Uncle Bob 의 Jacobson 인용)	use case 중심 설계	Jacobson 원전 출처 (책/논문) 가 본 글에 명시 없음 — 원전 직접 확인 별도 필요

Usage Boundaries / 적용 경계

이 자료가 직접 증명하는 것:
- SCREAM-C1~C4: Uncle Bob 블로그 글의 핵심 주장 verbatim — feature-first / use case-centric 패키지 분할의 철학적 근거
- SCREAM-C5: Uncle Bob 이 Jacobson 의 입장을 어떻게 인용했는지 (Jacobson 원전 아님)
이 자료가 증명하지 않는 것:
- "package-by-feature 가 공식 best practice" 라는 정당화 — 본 글은 Uncle Bob 의 개인 블로그 (cleancoder.com), Strength = engineering-blog. official-vendor-doc 으로 격상 금지.
- 구체적 패키지 분할 가이드 (예: features/{name}/{layer}/) — 본 글은 철학 진술까지만, 구체 구조는 Clean Architecture 책 21장 또는 ca-tmpl 자체 결정
- feature-first 가 layer-first 대비 정량 우위가 있다는 증거 (응집도/결합도 메트릭) — 본 글 범위 밖, Sahibinden 사례 / 별도 측정 필요
내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- "deferred decision" 의 ca-tmpl 구체 매핑 — 어느 시점까지 DB/web server 결정을 늦출 수 있는가의 기준
- ca-tmpl 의 features/ 디렉터리가 실제 "scream" 하는지 (외부 reviewer 가 한 번 봤을 때 도메인이 보이는지) 의 검증 절차
- 마이크로서비스 분리 시 feature-first 가 어떻게 module boundary 로 이어지는지 — 본 글 범위 밖

메모 / Notes (내 프로젝트 해석 — 자료 직접 인용 아님)

적용 시나리오: 도메인 의미가 분명한 비즈니스 시스템. CRUD-only 토이 프로젝트에는 과함.
장점: 최상위 디렉터리만 봐도 "이 시스템이 무엇인지" 드러남. Feature 단위로 잘려 있으면 향후 microservice 분리 비용이 낮음.
단점: 원문은 패키지 구조보다 "프레임워크에 종속된 사고방식" 비판에 집중. 구체적 패키지 가이드는 Clean Architecture 책 21장에 더 자세함.
ca-tmpl(feature-first)와의 차이: 동일한 철학. ca-tmpl의 features/{name}/{presentation,application,domain,infrastructure}는 이 원칙의 직접 구현체에 해당.

9.4 KiB Raw Permalink Blame History