[SRLT-97] 유비쿼터스 언어 문서 작성 #64
Conversation
- 카멜케이스 수정
- 도메인 모델 업데이트 - 용어 사전 업데이트
|
Note
|
| Cohort / File(s) | Summary |
|---|---|
테스트 유틸 강화src/test/java/starlight/application/businessplan/util/PlainTextExtractUtilsTest.java |
테이블 파싱 테스트 개선: 기존 테스트 데이터의 span 키를 소문자로 갱신하고, extractPlainText_tableWithLowercaseSpans() 및 extractPlainText_tableWithCamelCaseSpans() 두 테스트를 추가하여 lowercase/camelCase rowspan/colspan 처리 검증 |
유틸 로직 변경src/main/java/starlight/application/businessplan/util/PlainTextExtractUtils.java |
rowspan/colspan 추출 로직을 resolveSpanValue(JsonNode, String, String) 헬퍼로 통합해 소문자/카멜케이스 키를 모두 조회하고 최소값 1로 디폴트 처리하도록 수정(퍼블릭 시그니처는 불변) |
도메인 모델 정의도메인모델.md |
StarLight 도메인 전면 재정의: Member, Credential, Expert, BusinessPlan 및 5개 섹션(Overview, ProblemRecognition, Feasibility, GrowthTactic, TeamCompetence), SubSection, ExpertReport/ExpertReportDetail, AiReport, Orders, PaymentRecords, 값 객체(Money, OrderCode, RawJson) 및 다수의 enum(예: PlanStatus, SubmitStatus, MemberType, TagCategory) 추가/정의 |
용어사전 갱신용어사전.md |
기존 용어(창업자, 전문가) 설명 확장 및 StarLight 컨텍스트 반영; 회원, 사업계획서, 섹션/서브섹션, 피드백/리포트, 주문/결제 등 다수 도메인 용어의 한영 매핑 및 정의 추가 |
Estimated code review effort
🎯 4 (Complex) | ⏱️ ~45 minutes
- 주의 검토 항목:
- 도메인 모델: BaseSection/서브섹션 계층과 집계 경계의 적절성 검토
- 비즈니스 규칙: ExpertReport 만료·편집 규칙, Orders/PaymentRecords 상태 전이 검증
- 값 객체 불변성 및 생성자(조립) 로직 확인:
Money,OrderCode,RawJson - 유닛 테스트: PlainTextExtractUtils의 span 해석 헬퍼 경계(엣지 케이스) 및 포맷 결과 일관성 확인
Suggested labels
🧵 REFACTOR, ✂️ CHORE
Pre-merge checks and finishing touches
❌ Failed checks (1 warning)
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Docstring Coverage | Docstring coverage is 14.29% which is insufficient. The required threshold is 80.00%. | You can run @coderabbitai generate docstrings to improve docstring coverage. |
✅ Passed checks (2 passed)
| Check name | Status | Explanation |
|---|---|---|
| Description Check | ✅ Passed | Check skipped - CodeRabbit’s high-level summary is enabled. |
| Title check | ✅ Passed | PR 제목은 유비쿼터스 언어 문서 작성을 명시하고 있으며, 실제 변경사항(도메인모델.md, 용어사전.md 업데이트)과 부분적으로 일치합니다. 다만 코드 변경사항(PlainTextExtractUtilsTest.java, PlainTextExtractUtils.java)은 제목에 반영되지 않았습니다. |
✨ Finishing touches
- 📝 Generate docstrings
🧪 Generate unit tests (beta)
- Create PR with unit tests
- Post copyable unit tests in a comment
- Commit unit tests in branch
SRLT-97-QA-사항-반영
📜 Recent review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/main/java/starlight/application/businessplan/util/PlainTextExtractUtils.java(2 hunks)src/test/java/starlight/application/businessplan/util/PlainTextExtractUtilsTest.java(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/test/java/starlight/application/businessplan/util/PlainTextExtractUtilsTest.java
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: build-and-push
- GitHub Check: test
🔇 Additional comments (1)
src/main/java/starlight/application/businessplan/util/PlainTextExtractUtils.java (1)
160-166: row/colspan 케이스 호환 처리 👍 + 스펙 확인 포인트 한 가지
resolveSpanValue분리로rowspan/colspan과rowSpan/colSpan을 모두 지원하면서 최소값을 1로 보정하는 구조는 현재 그리드 빌드 로직(for (int r = 0; r < rowspan ...,for (int c = 0; c < colspan ...)과도 잘 맞습니다. 호출부에서도 명시적으로rowspan,rowSpan/colspan,colSpan을 넘겨줘서 의도가 분명해진 점이 좋습니다.다만 현재 구현은
0, 음수, 비정상 타입(문자열, boolean 등)인 경우도asInt(1)+Math.max(1, ...)조합 때문에 모두1로 보정됩니다.
- 예:
{"rowspan": 0}또는{"rowspan": "abc"}→ 내부적으로는rowspan = 1처리.- 이런 “잘못 들어온 span 값은 전부 1로 취급한다”는 정책이 도메인/프론트 쪽과 합의된 것인지 한 번만 더 확인해 주시면 좋겠습니다.
- 만약 “0 또는 음수 span은 데이터 오류로 간주하고 그대로 무시하거나(= 1이 아니라 0으로 처리) 로깅/에러로 보고 싶다”는 요구가 있다면,
resolveSpanValue안에서 값 범위에 따라 분기(예: 음수면 warn 로그 + 1로 보정, 0이면 전체 셀 스킵 등)를 조금 더 명시적으로 나누는 것도 고려해볼 수 있습니다.추가로, 같은 셀에
rowspan과rowSpan가 동시에 들어오는 경우 현재는lowerKey쪽만 사용하고camelKey는 무시하는데, “기존 lowercase 포맷 우선”이라는 정책이 맞는지만 공유/주석으로 남겨두면 이후 유지보수할 때 의도 파악에 도움이 될 것 같습니다.전반적으로 기능 개선 방향은 적절해 보이고, 위 두 포인트는 스펙/정책을 한 번 더 점검해보면 좋겠다는 정도입니다.
Also applies to: 289-298
Tip
📝 Customizable high-level summaries are now available in beta!
You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.
- Provide your own instructions using the
high_level_summary_instructionssetting. - Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
- Use
high_level_summary_in_walkthroughto move the summary from the description to the walkthrough section.
Example instruction:
"Divide the high-level summary into five sections:
- 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
- 📓 References — List relevant issues, discussions, documentation, or related PRs.
- 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
- 📊 Contributor Summary — Include a Markdown table showing contributions:
| Contributor | Lines Added | Lines Removed | Files Changed |- ✔️ Additional Notes — Add any extra reviewer context.
Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."
Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands and usage tips.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (6)
도메인모델.md (3)
18-20: 마크다운 스타일:_Aggregate Root_등 이탤릭 사용 vs 헤딩 규칙현재
회원(Member)이하로_Aggregate Root_,_Entity_,_Enum_같은 라인이 모두 이탤릭으로 표현되어 있어서 markdownlint MD036(no-emphasis-as-heading)에 계속 걸리는 구조입니다. 문서 린트 파이프라인을 맞추고 싶다면:
- 예:
_Aggregate Root_→#### Aggregate Root처럼 실제 헤딩 레벨로 승격하거나- 아니면 프로젝트 레벨에서 MD036을 비활성화/예외 처리하는 쪽을 한 번 결정해두면 좋겠습니다.
[즉각 수정까지는 아니지만, 팀 컨벤션 정리가 있으면 좋을 것 같습니다.]
56-83: Expert ↔ Member 관계를 한 줄로라도 명시해 두면 도메인 이해도가 훨씬 좋아집니다
전문가(Expert)어그리거트가 “Member와 독립적으로 존재하는 별도의 엔티티”라고 정의되어 있는데, 상단 도메인 설명과Member.memberType = EXPERT설정이 같이 존재해서, 읽는 사람이 “전문가는 로그인 계정(Member) 인가? 별도 프로필 엔티티인가?”를 헷갈릴 수 있습니다.제안입니다:
- Expert와 Member 사이의 관계를 명시하는 한 줄을 추가
- 예: “Expert는 로그인 계정인 Member(EXPERT 타입)를 기반으로 1:1로 생성되는 전문 프로필 엔티티이다 (memberId 보유).”
또는- “Expert는 서비스 운영자가 별도로 관리하는 전문가 엔티티이며, 로그인 계정(Member)과는 직접적인 키 연동이 없다.”
이 부분이 명확해지면, 인증/인가, 프로필 수정, 탈퇴 시 동작 등 이후 API 설계 논의가 훨씬 수월해질 것입니다.
347-426: 주문/크레딧/Money 용어를 한 번에 정리해 두는 것이 좋습니다
주문(Orders)블록과 하단 값 객체 정의를 같이 보면 약간의 용어/타입 불일치가 있어, 구현을 처음 보는 개발자가 혼동할 수 있습니다.
Orders
orderCode:String- 주문 코드 (유니크)
- 아래에
OrderCode값 객체가 별도로 정의되어 있는데, 실제 도메인에서OrderCode를 사용할지, 단순 문자열로 둘지가 모호합니다.price:Long- 주문 금액
- 하단에
Money(amount, currency)값 객체가 정의되어 있어, “주문 금액/결제 금액을 Money로 표현할지, Long + String으로 유지할지”가 문서 상에서 혼재돼 보입니다.usageProductCode:String- 사용 상품 코드
- 동시에 Enum
UsageProductType(“사용 크레딧 상품 타입”)도 정의되어 있어, 코드/타입/실제 크레딧 개념의 관계가 조금 애매합니다.- 하단
UsageProductType설명은 “사용 크레딧 상품 타입(1회권, 2회권 등)”으로, 용어사전의UsageCredit정의와도 맞물립니다.제안:
- 주문/크레딧 쪽 Ubiquitous Language를 한 번에 고정해 주세요.
- 예:
usageProductType: UsageProductType(내부적으로 코드 값을 가지는 Enum)
또는usageProductCode: String(= UsageProductType의 코드)라고 명시.UsageProductTypevsUsageCredit의 단어 역할도 구분(“상품 타입” vs “실제 사용권/잔액”)을 문서에 적어주면 좋습니다.- 금액 표현도
- “도메인 모델 레벨에서는 Money를 사용한다 (Orders.price, PaymentRecords.price의 타입/설명을 Money 기준으로 통일)”
- 혹은 “현재는 KRW 고정 Long 금액만 쓰고, Money는 향후 확장용”처럼 의도만 명확히 해 두면 이후 변경 시 혼선을 줄일 수 있습니다.
지금도 이해는 가능하지만, 이 부분을 살짝 정리해 두면 결제/크레딧 관련 도메인 논의가 훨씬 매끄러워질 것 같습니다.
용어사전.md (2)
5-7: ‘전문가’가 Member인지, 별도 엔티티인지 표현을 더 명확히 하면 좋겠습니다현재 용어 정의:
전문가: “사업계획서를 검토하고 피드백을 제공하는 회원. Member와 독립적으로 존재하는 별도의 엔티티이다.”회원: “StarLight 서비스를 이용하는 모든 사용자.”여기서 “회원”이라는 단어와 “Member와 독립적인 엔티티”라는 표현이 같이 있어서,
“전문가는 로그인 가능한 Member인가?”, “Member와 분리된 별도 도메인 주체인가?”가 모호할 수 있습니다.예를 들어 다음과 같이 풀어 쓰면 더 분명해질 것 같습니다.
- “StarLight에서 피드백을 제공하는 도메인 주체. 로그인 계정인 Member(EXPERT 타입)를 기반으로 별도 관리되는 Expert 엔티티이다.”
또는- “서비스 운영자가 별도로 등록/관리하는 전문가 도메인 엔티티이며, 로그인 계정(Member)과는 분리되어 있을 수 있다.”
도메인모델.md의 “Expert 어그리거트” 설명과도 같이 맞춰주면, 신규 팀원이 구조를 이해하기 훨씬 쉬울 것 같습니다.
20-23: ‘사용 크레딧(UsageCredit)’ vs 도메인모델의 UsageProductType 정합성용어사전에는:
사용 크레딧(UsageCredit): “전문가 피드백 신청에 사용하는 크레딧(이용권). 1회권, 2회권 등의 상품이 있다.”반면 도메인모델.md에는:
UsageProductTypeEnum: “사용 크레딧 상품 타입 (1회권, 2회권 등)”Orders.usageProductCode: String- 사용 상품 코드이 세 가지(UsageCredit, UsageProductType, usageProductCode)가 각각 무엇을 가리키는지 문서만 보고는 약간 헷갈립니다.
제안:
- UsageCredit 항목에 “실제 사용자에게 부여된 이용권/잔액 개념인지, 아니면 상품 타입(1회권/2회권)을 의미하는지”를 명시.
- 동시에
UsageProductType에 대한 용어사전 항목을 추가하거나, UsageCredit 설명에서 “UsageProductTypeEnum으로 관리되는 상품 타입”이라고 언급해서 두 용어의 관계를 한 번에 잡아주면 좋겠습니다.이렇게 맞춰두면 주문/결제/크레딧 설계 논의 시에 같은 단어로 이야기하기 훨씬 쉬워질 것 같습니다.
src/test/java/starlight/application/businessplan/util/PlainTextExtractUtilsTest.java (1)
71-91: lowercase rowspan/colspan 테스트는 OK지만, 2행 구조를 더 활용해도 좋겠습니다
extractPlainText_tableWithLowercaseSpans에서:
- 첫 번째 행:
"A"에rowspan: 2,"B"에rowspan: 1- 두 번째 행: 빈 배열
[]이라는 구조로, 결과가
[2 columns]["A", "B"]["", ""]가 되는 것을 검증하고 있습니다.
이 테스트만으로도 “rowspan이 있어도 예외 없이 올바른 2행 그리드가 생성된다”는 기본 동작은 잘 체크하고 있습니다. 다만, 추후 버그를 더 잘 잡고 싶다면:
- 두 번째 행에 실제 셀을 하나 넣어 두고
- 올바른 구현에서는
rowspan에 의해 첫 번째 컬럼이 비어 있고,- 잘못된 구현에서는 첫 번째 컬럼에 값이 들어가 버리는 식으로
rowspan이 없는 경우와 있는 경우의 차이가 명확히 드러나는 케이스로 강화하는 것도 고려해 볼 만합니다.현재 수준도 문제는 없지만, 향후 리팩터링 시 회귀 테스트로 더 든든해질 수 있는 포인트입니다.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
src/test/java/starlight/application/businessplan/util/PlainTextExtractUtilsTest.java(2 hunks)도메인모델.md(1 hunks)용어사전.md(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
src/test/java/starlight/application/businessplan/util/PlainTextExtractUtilsTest.java (1)
src/main/java/starlight/application/businessplan/util/PlainTextExtractUtils.java (1)
PlainTextExtractUtils(22-289)
🪛 markdownlint-cli2 (0.18.1)
도메인모델.md
18-18: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
40-40: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
49-49: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
59-59: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
75-75: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
88-88: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
116-116: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
125-125: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
139-139: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
147-147: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
157-157: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
166-166: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
176-176: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
185-185: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
206-206: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
229-229: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
238-238: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
250-250: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
268-268: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
301-301: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
312-312: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
320-320: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
330-330: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
348-348: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
378-378: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
398-398: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
405-405: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
410-410: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
418-418: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: test
- GitHub Check: build-and-push
🔇 Additional comments (2)
용어사전.md (1)
8-19: 사업계획서/섹션/리포트 관련 용어 정리가 잘 되어 있습니다
사업계획서,섹션,서브 섹션,개요/문제 인식/실현 가능성/성장 전략/팀 역량,전문가 리포트,리포트 상세,AI 리포트까지 도메인모델.md와 1:1로 대응되도록 잘 정리돼 있어서, 추후 API 설계나 화면 기획 문서에서도 그대로 재사용하기 좋아 보입니다.이 부분은 현재 상태 그대로 유지하셔도 충분히 좋습니다.
src/test/java/starlight/application/businessplan/util/PlainTextExtractUtilsTest.java (1)
23-27: 기존 content-array + table 테스트에 span 속성 명시 추가는 괜찮습니다
extractPlainText_fromContentArrayJSON에서 각 셀에rowspan/colspan을 1로 명시해 준 변경은, 새로운 테이블 파서 로직(rowspan/colspan을 읽는 구현)에 맞춘 자연스러운 보강으로 보입니다.
- 의미적으로는 기존과 동일한 2x2 테이블을 표현하면서,
- 이후 rowspan/colspan 처리 로직이 바뀌더라도 이 기본 케이스가 깨지지 않도록 하는 데 도움이 됩니다.
이 부분은 그대로 두셔도 괜찮아 보입니다.
src/test/java/starlight/application/businessplan/util/PlainTextExtractUtilsTest.java
Show resolved
Hide resolved
- 카멜케이스와 스네이크케이스 전부 허용 되도록 수정
📝작업 내용
🔎코드 설명
💬고민사항 및 리뷰 요구사항
비고 (Optional)
Summary by CodeRabbit
Tests
Documentation
✏️ Tip: You can customize this high-level summary in your review settings.