11 KiB
11 KiB
title, source_type, url, archive_url, status, confidence, tags, related_projects, related_branches, created, last_reviewed
| title | source_type | url | archive_url | status | confidence | tags | related_projects | related_branches | created | last_reviewed | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Spring Modulith 공식 레퍼런스 문서 | official-doc | https://docs.spring.io/spring-modulith/reference/index.html | raw | high |
|
|
|
2026-05-22 | 2026-05-27 |
Spring Modulith 공식 레퍼런스 문서
Layer:
raw/official-docs/— Spring Modulith 공식 reference 의 원문 발췌. Spring Boot 기반 modular monolith 의 vendor official 표준. ca-tmplTopic 1 — Architecture Layout대안 비교 (대안 3: modulith). ca-tmpl 의 feature-first 패키지 레이아웃과 가장 호환성 높은 공식 솔루션.
Parent / 활용 branch (필수)
이 자료는 혼자 존재하지 않는다. ca-tmpl architecture 결정 비교군의 한 축.
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-architecture-enforcement-rules | Spring Modulith 의 ArchUnit 기반 boundary 검증 + @ApplicationModuleTest 가 ca-tmpl enforcement 도구 후보 — 컨벤션을 컴파일/테스트 시점에 강제하는 공식 reference |
| raw/branch-notes/feature-skeleton-package-blueprint-contract | ca-tmpl 의 feature-first 패키지 레이아웃이 Spring Modulith 의 "Application Module = 메인 패키지의 직접 sub-package" 컨벤션과 정확히 매핑되는지 비교 근거 |
| raw/branch-notes/feature-domain-feature-onboarding-contract | 새 feature 추가 시 @NamedInterface 로 cross-module public API 를 명시하는 공식 워크플로우 — ca-tmpl 의 cross-feature 통신 규약 reference |
특정 branch 없이 foundational 조사로 수집한 경우:
- raw/project-notes/ca-skeleton-operational-contract — §20 Skeleton Blueprint Contract / §19 Domain Application Readiness Contract 의 대안 비교 (대안 3: modulith)
컨텍스트
ca-tmpl 의 feature-first 결정에 대한 대안 4: Spring Modulith (modular monolith) 의 공식 문서. ca-tmpl 의 feature-first 패키지 레이아웃과 가장 호환성 높은 공식 솔루션. "feature 를 패키지로 자르되 경계를 코드로 강제할 수 있는가" 라는 ca-tmpl 의 약점에 대한 공식 답이 될 수 있음.
출처 / Source
- 원본 URL: https://docs.spring.io/spring-modulith/reference/index.html
- 아카이브 URL: (미수집)
- 저자 / 조직: Spring Team (Pivotal/VMware/Broadcom 산하 spring-projects)
- 발행 상태: 지속 업데이트, 2026-03-27 v1.4 GA (Spring Boot 3.5 / Java 21 기준)
- GitHub: github.com/spring-projects/spring-modulith
- 마지막 확인일: 2026-05-27
- 재검증 한계: WebFetch 가 2026-05-27 introduction 페이지의 첫 3개 인용은 verbatim 확인. 4~5번 "(보강)" 인용 (Application Module = 직접 sub-package /
@NamedInterface) 은 introduction 페이지에 없음 — Fundamentals / Verifying Application Module Structure 하위 페이지에서 유래한 것으로 추정, 본 자료에서는needs-confirmation처리.
핵심 인용 / Key quotes (verbatim)
[§Introduction — opinionated toolkit] "Spring Modulith is an opinionated toolkit to build domain-driven, modular applications with Spring Boot."
[§Introduction — Spring Boot analogy] "In the same way that Spring Boot has an opinion on the technical arrangement of an application, Spring Modulith implements an opinion on how to structure an app functionally and allows its individual, logical parts to interact with each other."
[§Introduction — outcome] "As a result, Spring Modulith enables developers to build applications that are easier to update so they can accommodate changing business requirements over time."
[§보강 — Application module = sub-package (출처 미확정)] "Application modules are direct sub-packages of the main package, with subpackages contained in application modules considered internal and not to be referenced by code from other modules."
[§보강 — @NamedInterface (출처 미확정)] "@NamedInterface defines the explicit public API of a module, and only interfaces annotated with @NamedInterface are allowed as cross-module contracts."
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| MODULITH-C1 | Spring Modulith 는 Spring Boot 로 domain-driven, modular application 을 빌드하는 opinionated toolkit | [§Introduction — opinionated toolkit] "Spring Modulith is an opinionated toolkit to build domain-driven, modular applications with Spring Boot." | official-vendor-doc |
Spring Boot 3.x + Java 17+ 환경 | "opinionated" 의 구체 내용 — 어떤 컨벤션을 강제하고 어떤 것을 사용자 선택으로 두는지 — 는 본 인용에 없음 |
| MODULITH-C2 | Spring Modulith 는 Spring Boot 가 application 의 기술적 배열에 의견을 갖는 것과 같이, application 을 기능적으로 구조화하는 방법에 대한 의견을 구현하고, 각 logical part 들이 상호작용할 수 있도록 함 | [§Introduction — Spring Boot analogy] "In the same way that Spring Boot has an opinion on the technical arrangement of an application, Spring Modulith implements an opinion on how to structure an app functionally and allows its individual, logical parts to interact with each other." | official-vendor-doc |
functional decomposition 적용 의도 | "functional structure" 의 정확한 단위 (feature / bounded context / aggregate) 는 본 인용에 없음 — Fundamentals 별도 |
| MODULITH-C3 | Spring Modulith 는 비즈니스 요구사항 변경을 시간에 따라 수용하기 쉬운 application 을 개발자가 빌드할 수 있게 함 | [§Introduction — outcome] "As a result, Spring Modulith enables developers to build applications that are easier to update so they can accommodate changing business requirements over time." | official-vendor-doc |
장기 유지보수 의도 진술 | "easier to update" 가 정량적으로 어느 정도인지 (PR 사이즈 감소 / lead time 단축 등) 는 본 인용에 없음 — 측정 책임은 사용자 |
| MODULITH-C4 | Application module 은 main package 의 직접 sub-package 이며, application module 내부의 subpackage 는 internal 로 간주되어 다른 module 에서 참조되어서는 안 됨 | [§보강 — Application module = sub-package (출처 미확정)] "Application modules are direct sub-packages of the main package, with subpackages contained in application modules considered internal and not to be referenced by code from other modules." | needs-confirmation |
Spring Modulith 의 패키지 컨벤션 (출처 페이지 미확정) | introduction 페이지에는 부재 — Fundamentals 페이지 verbatim 재확인 필요. 본 인용을 official-vendor-doc 으로 격상 금지 |
| MODULITH-C5 | @NamedInterface 는 module 의 explicit public API 를 정의하며, @NamedInterface annotation 이 붙은 interface 만 cross-module contract 로 허용됨 |
[§보강 — @NamedInterface (출처 미확정)] "@NamedInterface defines the explicit public API of a module, and only interfaces annotated with @NamedInterface are allowed as cross-module contracts." | needs-confirmation |
@NamedInterface API 의 의도 (출처 페이지 미확정) |
"only interfaces annotated" 의 enforcement 방법 (compile-time vs ArchUnit runtime test) 은 본 인용에 없음 — 별도 페이지 검증 필요 |
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
MODULITH-C1~C3: Spring Modulith 의 정체성 (opinionated toolkit), Spring Boot 와의 유비, 의도 (장기 비즈니스 변경 수용) — WebFetch 2026-05-27 verbatim 확인
- 이 자료가 증명하지 않는 것 (introduction 페이지 범위):
- 패키지 컨벤션 의 정확한 verbatim (Application Module = 직접 sub-package) —
MODULITH-C4는 Fundamentals 페이지 확인 필요 @NamedInterface의 정확한 동작 —MODULITH-C5는 별도 페이지 확인 필요- ArchUnit 기반 boundary 검증 /
@ApplicationModuleTest/ ApplicationEvents / PlantUML 다이어그램 자동 생성 — user 메모이며 본 introduction 인용 범위 밖 - Spring Boot 3.x 이전 버전에서의 호환성
- "Modulith 가 Hexagonal/Onion 의 대체" 라는 입장 (Spring Modulith 는 자체 모델로 분류해야)
- 패키지 컨벤션 의 정확한 verbatim (Application Module = 직접 sub-package) —
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-tmpl 의 feature 가 Spring Modulith 의 "Application Module" 과 정확히 1:1 매핑되는지 (특히 sub-package internal 규칙)
- ca-tmpl 의 cross-feature 통신이
@NamedInterface+ApplicationEvents로 표현 가능한지 - ca-tmpl 위에
spring-modulith-starter-core를 단순 추가했을 때 기존 패키지가 module 로 자동 인식되는지 (또는@Modulithannotation 필요한지) - v1.4 (2026-03-27) 의 신규 기능 (Java 21 record 지원 등) 이 ca-tmpl 의 Java 버전 정책과 호환되는지
메모 / Notes (내 프로젝트 해석)
본 섹션은 자료 직접 인용 아님. ca-tmpl 비교 컨텍스트 해석.
- 적용 시나리오: monolith 로 시작하지만 향후 service 분리 가능성을 열어두고 싶을 때. 도메인 경계가 명확한 e-commerce, fintech, B2B SaaS.
- 장점: 공식 라이브러리. ArchUnit 기반 boundary 검증,
@ApplicationModuleTest로 모듈 단위 통합 테스트, ApplicationEvents 기반 모듈 간 비동기 통신, PlantUML 다이어그램 자동 생성 (user 메모 — introduction 인용 범위 밖). - 단점: 학습 곡선. 멀티 도메인이 명확하지 않은 단일 서비스에는 과함. Spring Boot 3.x 필수.
- ca-tmpl(feature-first) 와의 차이 (user 해석): 개념적으로 거의 동일 — Spring Modulith 의 "Application Module" 이 ca-tmpl 의 "feature" 에 대응 (단
MODULITH-C4의 verbatim 확정 후 강화 가능). 차이는 ca-tmpl 이 컨벤션 수준에 머무는 반면 Modulith 는 컴파일/테스트 시점 경계 강제. ca-tmpl 위에spring-modulith-starter-core를 추가하면 자연스럽게 진화 가능 (가설). - 신뢰도:
official-vendor-doc등급 (C1~C3만). Spring 공식 라이브러리이므로 기준/정의로 인용 가능.C4,C5는 출처 페이지 확정 전까지needs-confirmation.
Related / 관련
- 같은 주제 다른 official-doc:
- raw/official-docs/hexagonal-cockburn-wikipedia-summary (대안 2 — Hexagonal 원형)
- raw/official-docs/hexagonal-thombergs-buckpal-github (대안 2 — Java reference)
- raw/official-docs/onion-palermo-original-2008 (대안 5 — Onion 원형)
- 같은 주제 company-tech-blog:
- raw/company-tech-blogs/hexagonal-woowahan-techblog-2023 (한국 hexagonal 사례 — modulith 와는 다른 대안축)
- 인용하는 branch / project:
- 인용한 wiki 요약: (미작성)