Files

T

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

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

8.5 KiB

Raw 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

Package by Layer vs Package by Feature (Sahibinden Technology)

Layer: raw/company-tech-blogs/ — Sahibinden Technology (터키 최대 e-commerce 플랫폼 엔지니어링 블로그, Medium) 의 사례성 비교 글. ca-tmpl 의 feature-first 결정 강화 근거 (단, company-tech-blog 이므로 공식 best practice 아님).

Parent / 활용 branch (필수)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-architecture-enforcement-rules	"package-by-feature 의 package-private 가시성 활용" 을 ArchUnit 룰로 강제하는 근거
raw/branch-notes/feature-skeleton-package-blueprint-contract	`features/{name}` 패키지에서 내부 클래스 가시성을 `public` default 가 아닌 `package-private` 유도하는 blueprint 결정
raw/branch-notes/feature-domain-feature-onboarding-contract	신규 feature 온보딩 시 "한 패키지 내 응집도 + 외부 패키지와의 결합도" 체크리스트 근거

컨텍스트 / 왜 저장했는지

ca-tmpl의 feature-first 결정 근거 강화용. 사례 기반(공식 best practice가 아닌 회사 관점)으로 Package-by-Feature의 구체적 이점(encapsulation, navigation)을 비교 정리한 자료.

출처 / Source

원본 URL: https://medium.com/sahibinden-technology/package-by-layer-vs-package-by-feature-7e89cde2ae3a
아카이브 URL: (미확보)
저자: M. Enes Oral
조직: Sahibinden Technology (터키 최대 e-commerce 플랫폼 엔지니어링 블로그)
발행일: 2021-06-01
마지막 확인일: 2026-05-27

핵심 인용 / Key quotes (verbatim)

[§Package by Layer — cohesion] "This method causes low cohesion within packages because packages contain classes that are not closely related to each other."

[§Package by Layer — coupling] "high coupling occurs between packages" (Repository / Service / Controller 의존 맥락에서)

[§Package by Feature — encapsulation] "Package by Feature allows some classes to set their access modifier package-private instead of public, so it increases encapsulation."

[§Package by Feature — navigation] "Package by Feature reduces the need to navigate between packages since all classes needed for a feature are in the same package."

[§Package by Layer — scaling] "As an application grows in size, the number of classes in each package will increase without bound" (Package by Layer 의 한계 설명)

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
SAHIBINDEN-PBF-C1	Package-by-Layer 는 한 패키지 내 클래스들이 서로 밀접하지 않아 low cohesion 을 유발한다	[§Cohesion] "This method causes low cohesion within packages because packages contain classes that are not closely related to each other."	`company-case-study`	Java 백엔드 모놀리스의 패키지 구조 평가	"모든 layer-first 프로젝트가 low cohesion" 이라는 일반화는 아님 — 도메인이 단일하고 작으면 차이 미미
SAHIBINDEN-PBF-C2	Package-by-Layer 는 Repository/Service/Controller 의존 관계로 인해 패키지 간 high coupling 이 발생한다	[§Coupling] "high coupling occurs between packages"	`company-case-study`	layer 기반 패키지 분할 진단	정량 측정 (coupling metric, 예: efferent/afferent) 미제시 — 정성적 관찰
SAHIBINDEN-PBF-C3	Package-by-Feature 는 일부 클래스의 가시성을 `public` 대신 `package-private` 으로 둘 수 있어 encapsulation 이 증가한다	[§Encapsulation] "Package by Feature allows some classes to set their access modifier `package-private` instead of `public`, so it increases encapsulation."	`company-case-study`	Java 언어의 가시성 제어 활용	Kotlin/Scala 등 다른 JVM 언어의 가시성 모델에 그대로 적용된다는 뜻은 아님
SAHIBINDEN-PBF-C4	Package-by-Feature 는 한 기능에 필요한 클래스가 한 패키지에 모여 있어 패키지 간 navigation 비용 을 줄인다	[§Navigation] "Package by Feature reduces the need to navigate between packages since all classes needed for a feature are in the same package."	`company-case-study`	개발자 생산성 / IDE 탐색 측면 평가	navigation 시간 절감의 정량 데이터 (분/일) 미제시
SAHIBINDEN-PBF-C5	Package-by-Layer 는 application 규모가 커질수록 각 패키지 내 클래스 수가 무한정 증가 하는 한계가 있다	[§Scaling] "As an application grows in size, the number of classes in each package will increase without bound"	`company-case-study`	장기 운영 / 규모 확장 시나리오	"feature-first 는 그렇지 않다" 의 증거는 본 인용 직접 없음 — 별도 분할 정책으로 대응한다는 의미일 뿐

Usage Boundaries / 적용 경계

이 자료가 직접 증명하는 것:
- SAHIBINDEN-PBF-C1~C5: Sahibinden 엔지니어 (M. Enes Oral, 2021-06-01) 가 Package-by-Layer 의 단점과 Package-by-Feature 의 이점을 정성적으로 진단한 내용
이 자료가 증명하지 않는 것:
- "Package-by-Feature 가 공식 표준 best practice" 라는 정당화 — 본 글은 company-tech-blog (Strength = company-case-study). CLAUDE.md §5 "company-tech-blog → 공식 best practice 로 취급 금지" 명시.
- feature-first 의 정량 우위 (cohesion/coupling 메트릭) — 본 글은 정성적 관찰
- Sahibinden 자체의 production 채택 / 운영 측정 결과 — 본 글은 비교 논의, 실제 회사 코드베이스 적용 증거 미수록
내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-tmpl 에서 package-private 가시성을 실제로 활용하는 비율 — feature 패키지 내 ratio 측정 필요
- Spring Boot 의 @Service / @Repository 가 default public 가시성을 요구하는지 확인 (component scan 호환성)
- Sahibinden 외 다른 사례 (Naver / 카카오 / 우아한형제들 등) 의 동일 패턴 채택 여부 — 별도 ingest 필요 (단일 회사 글로 일반화 금지)

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

적용 시나리오: 도메인 수가 늘어나는 중규모 이상 monolith.
장점: package-private 가시성 활용 가능 → 자바 언어 차원에서 모듈 경계 강제. IDE 탐색 비용 감소.
단점: source_type이 company-tech-blog이므로 공식 best practice로 인용 금지. 회사 사례 수준의 신뢰도 (Strength = company-case-study).
ca-tmpl(feature-first)와의 차이: 인용된 encapsulation 이점은 ca-tmpl이 features/{featureName} 패키지를 둔 핵심 명분 중 하나. ca-tmpl은 여기서 한 단계 더 나아가 feature 안에서 다시 layer를 나눈 하이브리드.

8.5 KiB Raw Blame History