ghojeong/ddd-strategic-design

Pyro(波而爐)

자신있는 코드

• Java
  • Typesafe Heterogeneous Container
  • DI 프레임워크 바닐라 Java 로 구현
  • WAS 를 TDD로 구현
• Javascript
  • 비동기
  • redux-observable

경험

• Dreamfora: 2021 -
  • Kotlin, Android, Room, Hilt
• Ecube Labs: 2018 - 2020
  • Typescript, React, Redux, RxJS

교육

• 우아한테크코스 리뷰어
• NEXTSTEP 리뷰어
  • 만들면서 배우는 JPA
  • 만들면서 배우는 Spring
  • TDD, 클린 코드 with Java
• 코드스쿼드 백엔드 마스터즈 수료
• 한빛미디어 공감 주니어 강사
• 과학기술원 컴퓨터공학 성적 우수 졸업
  • 알고리즘 A+, 데이터구조 A, 데이터베이스 A-, 운영체제 A-, 네트워크 A-

보유기술

언어	Java Kotlin Typescript	리플렉션을 통해 커스텀 어노테이션을 만든 경험과, 코루틴을 활용한 병렬 상태관리 경험이 있습니다.
프레임워크	Spring Boot JPA Android React	JPA 를 사용한 경험을 바탕으로, 안드로이드에서 Repository 패턴을 직접 구현했습니다.
DB	MySQL SQLite	InnoDB 와 다른 스토리지 엔진의 락이 어떻게 다르게 걸리는지 이해하고 있습니다. 테이블 단위로 락이 걸리는 SQLite 의 트랜잭션에 반응하기 위해, 리액티브 프로그래밍을 도입하여, 렌더링 최적화를 해낸 경험이 있습니다.
인프라	Docker EC2 S3 IAM RDS CloutFront Route53	Docker 가 어떻게 독립된 cgroup 과 namespace 를 가지는지 프로세스 생성 과정을 추적한 경험이 있습니다. DB 를 private network 에 분리해야하는 필요성을 인지하고 있으며, Bastion Host 에 대해 알고 있습니다. IAM 에서 Role 을 통해 필요한 권한을 부여하는 법에 대해 알고 있습니다.

ddd-strategic-design's Issues

패키지 구성과 관련된 여러 자료

내가 했던 방법 : Root Aggregate 기준으로 바운디드 컨텍스트를 나누기

* domain : domain layer 
    - aggreagte, repository, domain service 와 같이 도메인에서 처리하는 클래스들을 위치 시키는 편입니다.
* application : application laeyr 
    - 응용 서비스(application service)를 모아두곤 합니다. 
* api : presentation layer 
    - controller, adaptor와 같이 외부 client의 요청을 받는 클래스를 모아둡니다. 
* infra : infrastructure layer 
    - 이메일, 메시지 알림등과 같은 외부 서비스와 관련된 클래스를 모아둡니다.
* dto
    - request, response, layer 간 데이터 이동을 위한 클래스를 정의합니다. 

• https://github.com/cheese10yun/spring-guide/blob/master/docs/directory-guide.md

• https://en.wikipedia.org/wiki/Package_principles

• https://medium.com/@ssowonny/package-by-feature-in-clean-architecture-projects-e14d25e3905e

• http://www.javapractices.com/topic/TopicAction.do?Id=205

• 마틴 파울러; Bounded Context

BOUNDED CONTEXT 중심의 패키지 구조로 리팩터링하기

계층 우선 패키지 구조를 BOUNDED CONTEXT 중심의 패키지 구조로 리팩터링한다.

Package by feature, not layer

PR 링크 정리

• next-step#66
• next-step#75
• next-step#79

2021년 8월 24일 화 수업 내용

도메인 분석

• 주문 도메인

• 주문 테이블 도메인

• 메뉴 도메인

• 상품 도메인

• Core Domain : 주문

• Support Domain: 주문테이블, 메뉴, 상품

• Common Domain : 비속어 필터

도메인을 나누는 것의 의미

• MSA -> 독립된 서비스가 된다.

• 모놀리식 -> 패키지가 된다.

• 멀티모듈 -> 모듈이 된다

• 조용호 우아한 객체지향

• 박용권 잘키운 모노리스

도메인 분석이 어렵다면 해외 서비스의 FAQ 페이지를 참고하자.
하나의 CS 팀이 모든 질문을 답할 수 없기 때문에, 나누어져 있는데
나눈 기준이 보통 도메인이 된다.

오늘 수업

Value Object 는 불변이다.
도메인 vs 모델:

• 모델(프라모델) 관심을 가지는 모양 (자바에서 모델은 클래스와 실제로 대응된다.)
• 도메인은 정말 넓은 "영역" (한 도메인에 여러개의 모델을 가진다.)
• 컨텍스트과 도메인은 n:m 관계이다. 컨텍스트는 용어가 다른 의미를 가지는지 구분짓는 역할을 한다.

• seq: 비즈니스 적으로 의미가 없는 식별자. -> Value Object
• id: 비즈니스적으로 의미가 있는 식별자 -> Entity

DDD 어려워하는 3가지

• Bounded Context
• Aggregate
• Domain Service

어휘 정리

• 컨텍스트: 용어사전의 용어의 의미가 달라질 수 있는 "맥락"

• 도메인: 모델들을 나누는 "영역", 도메인을 나눈 기준에 따라 앱의 책임을 쪼갤 수 있다.

  • MSA: 도메인을 기준으로 마이크로 서비스를 쪼갠다.
  • 모놀리식: 도메인을 기준으로 패키지를 쪼갠다.
  • 멀티모듈: 도메인을 기준으로 모듈을 쪼갠다.

• 모델: 도메인에 속한 실제 "관심사", java 에서는 클래스와 1대1 대응된다.

• 엔티티: 비즈니스 적으로 의미가 있는 ID 를 가진 객체

• VO: 불변 객체. 비즈니스 적으로 의미가 있는 식별자를 갖지 않는다. 그래서 id 대신 seq 로 객체를 식별한다.

• Aggregate

  • 어그리게잇이 곧 트랜잭션 단위
  • 비즈니스 일관성이 지켜져야 하는 VO 와 엔티티를 어그리게잇으로 묶는다.
  • 어그리게잇 단위로 ACID 와 생명주기가 맞춰진다.

• Repository

  • 어그리게잇의 트랜잭션을 가능케하는 실제 구현체
  • 리포지토리는 어그리게잇 단위로 존재하고, 테이블 단위로 존재하지 않는다.

• Domain Service

  • 상태가 없이 행위만 가지고 있는 클래스
  • Component 어노테이션을 주로 붙인다.
  • 한 어그리게잇에 넣기 애매한 로직을 도메인 서비스로 분리함
    • 위키로 관리해야하는 비즈니스 정책은 도메인 서비스이다.

전술적 설계 - Aggregate 와 Repository

Aggregate

• ** 어그리게잇이 곧 "트랜잭션" 단위다. **
• ACID 를 지켜야하는 혹은 생명주기를 맞춰야 하는 VO 와 엔티티를 어그리게잇으로 묶는다.
• 어그리게잇 단위로 비즈니스 일관성이 지켜진다.
• 어그리게잇이 곧 Building Block 이 된다.

Root Entity == Aggregate Root

• Root Entity 의 ID 를 Global 식별자라고 부른다.
• 반대로 Root 가 아닌 Entitiy 의 ID 는 Local 식별자라고 부른다.
• Global 식별자를 가진자가 Aggregate Root 가 된다.

Repository

• 일관성을 지켜주는 구현체
• 어그리게잇 단위로 CRUD 의 ACID 를 지켜주는 구현체
• 리포지토리는 어그리게잇 단위로 존재하고 테이블 단위로 존재하지 않는다.

도메인 서비스

• 상태가 없이 행위만 가지고 있음
• 한 어그리게잇에 넣기 애매한 로직을 도메인 서비스로 분리함
  • 위키로 관리해야하는 비즈니스 정책은 도메인 서비스이다.