포스트

2021-10-17-TIL

TIL
게시 수정 작성자 August
좋아요 조회 9 분 읽는 시간
  1. docs(posts): separate the sections of every post with a thematic break +8 −0
  2. docs(posts): write every reference entry as title, then publisher +4 −4
  3. docs(til): write up the link-only tils from late 2020 to early 2022 +51 −1
  4. 처음 게시

2021-10-17-TIL

Greenion 프로젝트 회의

이벤트 스토밍

DDD와 이벤트 스토밍에 대해서 관련 영상을 미리 보고나서 다같이 이벤트 스토밍을 진행하였다. 무료는 4명까지 가능하지만 Miro라는 툴을 사용하여 이벤트 스토밍을 수월하게 진행할 수 있었다. 유저도메인과 피드도메인 까지만 완성을 했는데, OAuth2.0의 흐름과 간단한 피드 위주로 작성하였다. 영상에서는 30분 내지 1시간내로 빠르게 수행하여 다 끝내는 것 처럼 설명하였는데, 우리는 아직 익숙지않아서 그런지 이 두 가지 도메인에 대해 스토밍 하는데만 2시간 가까이 걸렸다. 하다보면 늘 것이라 믿는다.

이벤트스토밍 툴: https://miro.com 관련영상: https://www.youtube.com/watch?v=F7EnW8dfetU

이벤트 스토밍은 알베르토 브랜돌리니가 고안한 워크숍 방식으로, 개발자와 도메인 전문가가 함께 벽(또는 온라인 화이트보드)에 포스트잇을 붙이며 도메인을 탐색한다. 진행 순서는 대략 이렇다.

  1. 도메인 이벤트: “회원이 가입했다”, “피드가 작성되었다”처럼 비즈니스에서 일어난 일을 과거형으로 적고 시간 순서대로 늘어놓는다.
  2. 커맨드와 액터: 각 이벤트를 일으킨 명령(“피드 작성”)과 그 명령을 내린 사람이나 역할을 붙인다.
  3. 외부 시스템과 정책: OAuth 제공자처럼 바깥 시스템이 관여하는 지점, “가입하면 환영 알림을 보낸다” 같은 자동 반응 규칙을 표시한다.
  4. 애그리거트와 경계: 같은 데이터를 중심으로 모이는 커맨드와 이벤트를 묶어 애그리거트를 찾고, 이를 바탕으로 바운디드 컨텍스트를 나눈다.

이벤트에서 출발하기 때문에 테이블 구조가 아니라 비즈니스 흐름을 중심으로 대화하게 된다는 점이 장점이다.

DDD

도메인 주도 설계(DDD)는 에릭 에반스가 2003년 책으로 정리한 설계 접근으로, 복잡한 비즈니스 도메인을 코드의 중심에 두고 모델링한다. 링크된 글들이 다루는 핵심 개념은 다음과 같다.

  • 유비쿼터스 언어: 개발자와 도메인 전문가가 같은 용어를 쓰고, 그 용어가 코드의 클래스와 메서드 이름에도 그대로 나타나게 한다.
  • 바운디드 컨텍스트: 같은 단어라도 맥락에 따라 의미가 다르므로(주문 맥락의 “회원”과 정산 맥락의 “회원”) 모델이 유효한 경계를 나눈다. 마이크로서비스를 나누는 기준으로도 쓰인다.
  • 전술적 패턴: 식별자로 구분하는 엔티티, 값으로 구분하는 값 객체, 일관성을 함께 지켜야 하는 객체 묶음인 애그리거트, 애그리거트를 저장하고 꺼내는 리포지토리, 도메인 이벤트 등이 있다.

이벤트 스토밍이 전략적 설계(컨텍스트 나누기)의 출발점이라면, 전술적 패턴은 나눈 컨텍스트 안을 코드로 구현하는 도구다.

  • https://www.reimaginer.me/entry/DDD-start-book-review
  • https://huisam.tistory.com/entry/DDD
  • https://medium.com/react-native-seoul/%EB%8F%84%EB%A9%94%EC%9D%B8-%EC%A3%BC%EB%8F%84-%EC%84%A4%EA%B3%84-domain-driven-design-in-real-project-1-%EB%8F%84%EB%A9%94%EC%9D%B8-83a5e31c5e45
  • https://helloworld.kurly.com/blog/road-to-ddd/
  • https://cyberx.tistory.com/57
  • https://dddstudy.medium.com/ddd-3%EA%B8%B0-%EA%B0%9C%EB%B0%9C%EC%9E%90-%EC%A7%81%EA%B5%B0%EC%84%B8%EC%85%98-cbf29feb3fe8
  • https://tech.junhabaek.net/ddd-%EC%A0%84%EB%9E%B5%EC%A0%81-%EC%84%A4%EA%B3%84-event-storming-%EC%9D%B4%EB%B2%A4%ED%8A%B8-%EC%BB%A4%EB%A7%A8%EB%93%9C-%EC%99%B8%EB%B6%80%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%95%A1%ED%84%B0-23ea8af1f457

Design Pattern

링크된 글들이 다루는 패턴은 네 가지다.

  • 프록시 패턴: 실제 객체 앞에 같은 인터페이스를 가진 대리 객체를 두고, 접근 제어, 지연 생성, 부가 기능(로깅, 트랜잭션)을 끼워 넣는다. Spring AOP와 JPA 지연 로딩 프록시가 이 구조다.
  • 템플릿 메서드 패턴: 알고리즘의 뼈대를 상위 클래스의 메서드에 고정하고, 단계별 세부 구현은 하위 클래스가 오버라이드한다. 공통 흐름은 재사용하고 달라지는 부분만 바꾼다.
  • 빌더 패턴: 생성자 인자가 많거나 선택 인자가 섞인 객체를 단계적으로 조립한다. 인자의 순서를 외울 필요가 없고 각 값의 이름이 코드에 드러난다.

  • 팩토리 메서드 패턴: 객체 생성 인터페이스는 상위 클래스가 정하고, 어떤 구체 클래스를 만들지는 하위 클래스가 정한다.

  • https://limkydev.tistory.com/79
  • https://gmlwjd9405.github.io/2018/07/13/template-method-pattern.html
  • https://jusungpark.tistory.com/14
  • https://4z7l.github.io/2021/01/19/design_pattern_builder.html#:~:text=GoF%20%EB%94%94%EC%9E%90%EC%9D%B8%20%ED%8C%A8%ED%84%B4%20%EC%A4%91%20%EC%83%9D%EC%84%B1,%ED%95%98%EB%8A%94%20%EB%B0%A9%EB%B2%95%EC%9D%84%20%EC%A0%9C%EA%B3%B5%ED%95%9C%EB%8B%A4.
  • https://ko.wikipedia.org/wiki/%ED%8C%A9%ED%86%A0%EB%A6%AC_%EB%A9%94%EC%84%9C%EB%93%9C_%ED%8C%A8%ED%84%B4#:~:text=%ED%8C%A9%ED%86%A0%EB%A6%AC%20%EB%A9%94%EC%84%9C%EB%93%9C%20%ED%8C%A8%ED%84%B4(Factory%20method,%ED%95%98%EB%8F%84%EB%A1%9D%20%ED%95%98%EB%8A%94%20%ED%8C%A8%ED%84%B4%EC%9D%B4%EA%B8%B0%EB%8F%84%20%ED%95%98%EB%8B%A4.

Spring

Spring REST Docs

Spring REST Docs는 테스트 코드로 API 문서를 만드는 도구다. 공식 프로젝트 페이지 설명대로 Asciidoctor로 직접 쓴 문서와 Spring MVC 테스트(또는 WebTestClient, REST Assured)가 자동 생성한 스니펫을 합친다. 테스트가 통과해야 스니펫이 만들어지므로 문서가 실제 API와 어긋나지 않는다는 것이 Swagger처럼 애너테이션으로 문서를 만드는 방식과의 차이다.

  • https://spring.io/projects/spring-restdocs

Bean Factory

BeanFactory는 Spring IoC 컨테이너의 가장 기본 인터페이스로, 빈의 생성과 조회, 의존성 주입을 담당한다. ApplicationContext는 BeanFactory를 확장해 메시지 소스, 이벤트 발행, 환경 설정 같은 기능을 더한 것이다. Spring 문서는 특별한 이유가 없다면 ApplicationContext를 쓰라고 권장한다.

  • https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#beans-beanfactory

Unit Test

단위 테스트를 왜 써야 하는지와 작성 방법, 주니어 개발자를 위한 샘플 코드를 다룬 글이다. 테스트 대상의 의존성은 목 객체로 대체해 그 클래스의 로직만 검증하고, given-when-then 구조로 준비, 실행, 검증을 나눠 쓰면 읽기 쉽다.

  • https://brunch.co.kr/@springboot/418
  • https://galid1.tistory.com/783

JavaScript

var, let, const

var는 함수 스코프이고, 선언이 함수 맨 위로 끌어올려져(hoisting) 선언 전에 접근해도 undefined가 나오며, 같은 이름으로 다시 선언할 수 있다. ES2015의 let과 const는 블록 스코프이고, 선언 전에 접근하면 ReferenceError가 나며(TDZ, Temporal Dead Zone), 재선언이 안 된다. const는 재할당만 막을 뿐 가리키는 객체의 내부 변경은 막지 않는다. 기본은 const, 재할당이 필요할 때만 let을 쓰는 것이 일반적이다.

  • https://velog.io/@bathingape/JavaScript-var-let-const-%EC%B0%A8%EC%9D%B4%EC%A0%90
참고한 자료외부 출처 4

외부 출처

TIL, 2021-TIL
TIL
이 글은 저작권자의 CC BY 4.0 라이선스를 따릅니다.

댓글

아직 댓글이 없습니다