donghyeon.kang/llm-wiki
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
main
llm-wiki/raw/company-tech-blogs/modulith-arawn-github-modular-monoliths-spring.md
T

8.5 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 tags related_branches related_projects created last_reviewed
arawn/building-modular-monoliths-using-spring (박용권, 우아한형제들 발표 동반 코드) company-tech-blog https://github.com/arawn/building-modular-monoliths-using-spring raw medium
ca-architecture-layout
modulith
modular-monolith
arawn
woowahan
ddd
feature-architecture-enforcement-rules
feature-skeleton-package-blueprint-contract
feature-domain-feature-onboarding-contract
ca-skeleton-operational-contract
2026-05-22 2026-05-27

arawn/building-modular-monoliths-using-spring

Layer: raw/company-tech-blogs/ — 박용권 (당시 우아한형제들) GitHub repository 의 README 와 동반 코드. 2020 "잘 키운 모노리스 하나 열 마이크로서비스 안 부럽다" 발표의 reference 구현체 — Spring Modulith 등장 이전 한국 커뮤니티의 모듈형 모노리스 사실상 표준 사례. 검증된 요약은 /ingest 후 wiki/concepts/에 별도 작성. 원본은 raw에 영구 보관.

Parent / 활용 branch (필수)

Branch 이 자료가 정당화하는 결정
raw/branch-notes/feature-architecture-enforcement-rules 응집/결합을 아키텍처 스타일보다 우선시한다는 원칙 — ca-tmpl 의 enforcement rule 우선순위 근거
raw/branch-notes/feature-skeleton-package-blueprint-contract 도메인 중심 패키지 구조 (catalogs/orders/shipments) 사례 — ca-tmpl 의 features/{name} 구조 reference
raw/branch-notes/feature-domain-feature-onboarding-contract 모듈을 도메인 단위로 추출하는 onboarding 패턴의 reference 사례
raw/project-notes/ca-skeleton-operational-contract §20. Skeleton Blueprint Contract + §19. Domain Application Readiness Contract — feature-first 결정의 한국 커뮤니티 reference

컨텍스트 / 왜 저장했는지

ca-tmpl 의 feature-first 결정에 대한 대안 4: Spring Modulith 등장 이전 한국 커뮤니티에서 가장 많이 인용된 modular monolith reference. Spring 공식 도구 없이 "어떻게 경계를 만들 것인가" 를 단계별로 보여주는 자료로, ca-tmpl 의 feature-first 가 다음 단계로 가려면 무엇이 필요한지 보여줌.

출처 / Source

핵심 인용 / Key quotes (verbatim)

[§README — 목적] "스프링을 기반으로 모듈형 모노리스를 만들기 위한 방안을 공유합니다."

[§README — 원칙] "나는 응집과 결합을 다스리는 것이 아키텍처 스타일보다 먼저라고 말하고 싶다."

[§README — 설계 원칙] "높은 응집도(Cohesion)와 느슨한 결합도(Coupling)라 생각한다."

[§README — 진행 단계] "step_1: modularization - 도메인 중심 모듈화와 모듈간 의존성 관리"

[§README — 진행 단계] "step_2: encapsulation and separately - 모듈을 보호하고, 모듈간 의존성 분리"

[§README — 진행 단계] "step_3: context boundaries - 모듈 자율성을 지키는 컨텍스트 경계"

[§README — 도메인 구조] "핵심 도메인으로 상품(catalogs), 주문(orders), 배송(shipments)을 추출"

Claims Extracted / 추출된 주장

Claim ID Claim (이 자료가 직접 말하는 것) Evidence quote Strength Applies to Does not prove
ARAWN-MOD-C1 repository 의 목적은 Spring 기반 모듈형 모노리스 구성 방안 공유 [§README — 목적] "스프링을 기반으로 모듈형 모노리스를 만들기 위한 방안을 공유합니다." engineering-blog Spring + 모듈형 모노리스 학습/설계 사례 "방안" 이 prod 환경에서 검증된 표준이라는 뜻은 아님 — 학습/발표용 reference
ARAWN-MOD-C2 저자의 핵심 주장: 응집과 결합을 다스리는 것이 아키텍처 스타일보다 먼저 [§README — 원칙] "나는 응집과 결합을 다스리는 것이 아키텍처 스타일보다 먼저라고 말하고 싶다." + [§README — 설계 원칙] "높은 응집도(Cohesion)와 느슨한 결합도(Coupling)라 생각한다." engineering-blog 모듈 분할 원칙 우선순위 결정 "아키텍처 스타일이 무의미하다" 는 뜻은 아님 — 우선순위만 명시
ARAWN-MOD-C3 모듈화 진행은 3단계: (1) 도메인 중심 모듈화 + 의존성 관리, (2) 캡슐화 + 모듈간 의존성 분리, (3) context boundaries 로 모듈 자율성 확보 [§README — 진행 단계] "step_1: modularization - 도메인 중심 모듈화와 모듈간 의존성 관리" + "step_2: encapsulation and separately - 모듈을 보호하고, 모듈간 의존성 분리" + "step_3: context boundaries - 모듈 자율성을 지키는 컨텍스트 경계" engineering-blog 모듈형 모노리스 점진적 채택 로드맵 각 step 의 구체적 도구 (package-private / ApplicationEvent / DDD bounded context 등) 의 선택은 본 인용 범위 밖
ARAWN-MOD-C4 패키지 구조는 도메인 중심 (catalogs, orders, shipments) — 기술 layer 분할이 아닌 도메인 분할 [§README — 도메인 구조] "핵심 도메인으로 상품(catalogs), 주문(orders), 배송(shipments)을 추출" engineering-blog 도메인 단위 최상위 패키지 결정 feature 안의 내부 구조 (4-layer 등) 는 본 인용 범위 밖 — ca-tmpl 의 features/{name} 내부 layer 결정은 별도

Usage Boundaries / 적용 경계

  • 이 자료가 직접 증명하는 것:
    • ARAWN-MOD-C1: repository 의 목적 (Spring 모듈형 모노리스 방안 공유)
    • ARAWN-MOD-C2: 응집/결합 우선 원칙 (저자 주장)
    • ARAWN-MOD-C3: 3단계 점진적 모듈화 로드맵
    • ARAWN-MOD-C4: 도메인 중심 패키지 구조 사례
  • 이 자료가 증명하지 않는 것:
    • 이 패턴이 한국 백엔드의 "공식 best practice" — engineering-blog 수준 (개인 GitHub repo + 발표). 우아한형제들 사내 표준이라는 보장 없음
    • Spring Modulith 도입 후에도 이 패턴이 권장된다는 주장 (Spring Modulith 와의 비교는 본 자료에 없음)
    • 경계 위반의 컴파일/테스트 단계 검출 메커니즘의 충분성 (저자가 "팀 컨벤션 유지" 강조)
  • 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
    • ca-tmpl 의 features/{name} 안 4-layer 구조와 arawn 의 도메인 단위 모듈의 분할 차이 (layer 강제 vs 자유)
    • Spring Modulith 도입 시 본 패턴이 어떻게 마이그레이션되는지

메모 / Notes (내 프로젝트 해석)

본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.

  • 적용 시나리오: Spring Modulith 도입 전 (또는 Boot 2.x 환경) 에서 모듈 경계를 만들고 싶은 팀.
  • 장점: 도구가 아니라 "원칙" 중심. package-private 가시성, ApplicationEvent 기반 통신 등을 손으로 구현하며 모듈 분리 원리 학습.
  • 단점: Spring 공식 도구 부재 → 경계 위반 시 컴파일/테스트 차원 검증 약함. 팀 컨벤션 유지가 핵심.
  • ca-tmpl(feature-first) 와의 차이: arawn 자료는 도메인 = 모듈 = 최상위 패키지 라는 점에서 ca-tmpl 과 정확히 같은 발상. ca-tmpl 의 features/{name} 은 arawn 의 catalogs/, orders/ 와 1:1 매핑. 차이는 ca-tmpl 이 feature 안에 4-layer 를 두는 반면 arawn 자료는 layer 분할은 케이스마다 다름.
  • 신뢰도: engineering-blog (저자가 우아한형제들 시기, 개인 GitHub repo + 발표). 사례/관점으로 사용.

Related / 관련

Reference in New Issue View Git Blame Copy Permalink