2021-10-18-TIL

게시 2021/10/18 수정 2026/10/07 작성자 August

조회 4 분 읽는 시간

2026-10-07 docs(posts): separate the sections of every post with a thematic break +6 −0
2026-10-07 docs(posts): write every reference entry as title, then publisher +4 −4
2026-10-06 docs(til): fill out the thin late-2021 and early-2022 tils +37 −3
2021-10-18 처음 게시

Greenion 프론트 회의

DDD 방식으로 설계하는 방식에 대한 공유
UI 대략적인 그림 및 흐름 기존의 기획대로. 참조할만한 타 애플리케이션 -> 모야모, 식물119, PictureThis, plantgram
추가적인 아이디어 지운: 메타버스를 마이페이지의 프로필에 도입하여 나의 정원을 볼 수 있고 돌아다닐 수 있게 하는것도 재밌을 것 같다.
프론트 소통 활성화 방안 프론트엔드 슬랙 채널을 별도로 만들어서 프론트 지식과 기술 등을 활발하게 소통하도록 함
API 문서툴 swagger vs postman vs spring rest docs
커밋의 단위 -> 백엔드, 프론트엔드 끼리 추가 논의
- https://tech.10000lab.xyz/git/git-commit-discipline.html
프로젝트, 이슈, 위키 등 깃허브 기능을 십분 활용할 것

회의에서 나온 용어 정리

DDD

DDD(Domain-Driven Design)는 복잡한 업무 규칙을 도메인 용어에 기반한 모델을 중심으로 정리하는 설계 접근이다. 에릭 에반스가 2003년 책에서 정리했다. 마틴 파울러는 그 핵심으로 두 가지를 꼽는다. 하나는 개발자와 도메인 전문가가 같은 말을 쓰고 그 말을 코드에도 그대로 반영하는 보편 언어(Ubiquitous Language)다. 다른 하나는 큰 도메인을 의미가 일관된 경계로 나누는 바운디드 컨텍스트(Bounded Context)다. 엔티티, 값 객체 같은 분류도 이 책에서 나왔다.

API 문서 도구 세 가지

세 도구는 문서를 만드는 출발점이 다르다.

도구	문서의 출발점	특징
Swagger (OpenAPI)	코드의 애너테이션이나 명세 파일	OpenAPI 명세는 소스 코드 없이도 HTTP API의 기능을 이해할 수 있게 하는 언어 중립적인 표준이다. 명세로부터 문서 화면과 호출 도구를 만든다.
Postman	요청을 모아 둔 컬렉션	컬렉션을 만들면 요청 정보와 인증 방식, 예제 코드를 담은 기본 문서가 자동으로 생성된다.
Spring REST Docs	테스트 코드	테스트가 만든 요청과 응답 스니펫으로 문서를 조립한다. 스니펫이 틀리면 테스트가 실패하므로 문서와 실제 동작이 어긋나지 않는다.

Spring REST Docs는 문서의 정확성을 테스트로 보장하는 대신, 문서화할 API마다 테스트를 작성해야 한다. 그래서 이 선택은 팀이 테스트를 얼마나 쓰는지와 함께 정하게 된다.

커밋의 단위

참고 링크는 커밋을 작고 논리적인 단위로 나누는 규율에 관한 글이다. 한 커밋에 하나의 변경 의도만 담으면 리뷰하기 쉽고, 문제가 생겼을 때 되돌리거나 원인을 찾기도 쉽다.

참고한 자료외부 출처 4

외부 출처

DomainDrivenDesignMartin Fowler
OpenAPI SpecificationOpenAPI Initiative
Documenting your APIPostman Docs
Spring REST Docs ReferenceSpring Docs

TIL, 2021-TIL

TIL