카테고리 없음

2024-10-27 DDD 오프라인 파트 4 전략적 설계

백엔드 개발자 2024. 10. 27. 17:31

 

전략적 설계

 

아키텍처의 경계는 부서 구조의 경계에 따른다.

 

도메인 모델은 하나로 만들지 말고 여러개를 만든다. 그리고 그중 중요한 곳에 집중해라.

 

 

 

응집도

 = 단일 책임원칙.

 

 

 

 

 

처음에는 단일 도메인 모델로 시작한다.

요구사항이 추가될수록 커진다.

 

 

 

회사가 커지고 조직이 나뉘면 대화가 단절되고 코드는 계속 충돌나는 등 문제가 생긴다.

 

 

 

 

 

1개의 커다란 도메인 모델은 비현실적이다.

 

 

 

 

사용되는 컨텍스트에 따라 모델 분리

 

 

 

 

 

 

 

 

 

이상적으로 찢어지지는 않는다.

조직을 이상적으로 찢지 않아서.

 

 

 

 

 

 

 

 

 

 

바운디드 컨텍스트는 조직단위로 나뉜다.

 

 

 

 

 

 

암묵적으로 안하면 싸움이 남.

여러팀이 협력할때는 관계를 잘 정의해라.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

전략적 디스틸레이션

우선순위를 두세요

회사입장에서 힘을 실어주는 곳이 있어야 한다는 의미.

 

 

 

 

 

 

코어 도메인

 

도메인 -> 서브 도메인으로 나누고

도메인중 코어 도메인을 식별해서 실력자를 배정해라.

 

 

 

 

제네릭 서브도메인

타사와 공통으로 존재하는 서브도메인. 

비즈니스에 경쟁 우위를 제공하지 않는 것.

 

 

 

 

지원 서브 도메인

경쟁 우위는 제공하지 않지만

비즈니스 일부로 코어 도메인 지원

 

 

 

 

 

 

 

 

 

 

 

에릭 에반스는 파트3, 파트4가 핵심이라고 한다. 현재까지 얘기는 기존의 순수한 DDD 내용.

 

 

 

 

 

 

 

 

도메인 주도 설계 그 후

 

 

 

 

 

 

 

도메인 주도 설계 구현

 

현재 DDD 체계 정립.(자바에서의 구현)

현재의 체계는 대다수 이사람을 따른다.

 

 

 

 

 

사람들이 안읽는 뒷부분을 앞으로 가져왔다.

이사람만의 하나의 관점이니, 정답은 아니다. 조직마다 맞게 적용하면 된다.

 

 

 

 

 

 

 

 

 

 

이상적인게 서브 도메인

현실적으로 나뉜게 바운디드 컨텍스트

 

 

 

 

 

 

 

 

 

 

 

 

주문이 끝남.

주문이 늘어나야 됨.

 

 

 

 

애그리게이트 상태가 변경되었을때 외부에 알려주는게 도메인 이벤트이다.

 

 

 

 

 

 

 

 

 

 

 

반드시 이벤트처리를 하라는 얘기는 아님.

필요한 것만 가져 사용해라.

트레이드 오프해라.

 

 

 

 

이벤트 소싱

애그리게이트당 바뀌면 도메인이벤트를 발행함.

 

이벤트 스토어라는 곳에 다 저장.

 

 

보통 DB는 최종상태만 저장한다.

애그리게이트가 있을때, 

중간 변화과정을 다 저장하고 싶을때 사용

git과 같다.

 

그 도메인 이벤트를 저장하는 곳이 이벤트 스토어

최종상태를 저장하지 아니라 이벤트 자체를 저장하므로, DB를 안쓴다.

 

 

 

 

책임이 과도해진 도메인 모델

조회랑 아무 상관이 없음.

DDD는 CUD에만 생각하기.

 

 

 

 

 

 

 

CQRS

트래픽 많은 서비스에서는 많이 사용한다.

 

 

 

 

 

MSA의 유행

MSA와 DDD는 별도. 서로 적용하지 않아도 된다.

MSA를 할때, 무조건 DDD를 해야하는건 아님.

 

 

 

 

헥사고날 아키텍처

 

DDD와 상관 없음.

서로 별도의 개념.

 

이전에는 외부시스템 연동이 적었으나, 저시점에 많아짐.

api가 뚫고 들어온다. 사용자입력 뿐만 아니라 외부의 입력도 동일하게 동작할 수 있도록 하는게 필요했음.

동일한 로직을 서로다른 input과 output에 다 사용하고 싶다는 취지로 사용됨.

이게 MSA에 적합했음.

 

 

 

도메인 주도 설계의 재조명

 

 

MSA에서 서비스를 나누는 방법중 하나가 바운디드 컨텍스트라는 얘기.

강하게 결합하면 오해가 많아지므로 주의.

 

 

 

 

 

 

 

기술적인거 바깥쪽으로, 비즈니스를 안쪽으로. 방식이 다른정도의 차이.

DDD를 하는데 좋은 아키텍처들이다 정도지,

꼭 이걸 사용해야지 DDD는 아니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

DDD

 

어떤걸 하고 싶은지 명확하게 해야함.

 

조직의 체계 묶는 것

아키텍쳐(헥사고날등등)

생각하는게 전부 다르다.

 

 

무언가를 적용할때 목적이나 취지가 아니라 

어떻게 하면 되는지 적용하는 건 좋지 않다.

 

DDD는 위험하다. 

 

 

 

 

 

 

 

 

 

 

 

 

QnA

 

1.jpa 쓸때 jpa 엔티티로 애그리게이트를 만든다고 할때 리포

 

jpa가 오더가 바뀌었을때 cascade 옵션을 쓰면 뒤 부분도 달라짐. 편한 부분.

jpa로 애그리게이트 만듬

 

오더가 안바뀌고 오더 아이템이 바뀌는게 오히려 어려움.

jpa도 수정된 것만 업데이트 됨.

해결방법으로 jpa한테 연관관계로 바뀌어있는 애가 바뀌면 전체다 바뀌도록 옵션을 줄 수 있음.

 

jpa를 안쓴다면 오더와 오더라인 아이템 2가지 리포지토리가 있다면

오더에 오더라인 아이템에대한 쿼리가 다 들어가 있어야 함.

그 후 별도의 리포지토리를 안만드는 방식 사용해야 한다.

 

jpa를 쓰기 껄끄럽다면 spring data jdbc를 사용하면 깔끔하다.

 

 

2. 완전한 도메인 부분 격리

 

어떻게 가능한지?

 

어플리케이션짤때 여러 관심사가 있음

ui, infrastructure(DB, 연동) 2개는 쉬움

 

aplication 로직과 도메인로직(2개 합쳐서 비즈니스 로직)

이 어려움.

 

도메인 로직 : 기술적인 용어를 다 뺀 내용( 쿠폰을 쓰고 마일리지 적용)

도메인 로직에 도메인에 관련된 것들만 구현하는 것

 

애플리케이션 로직 : ui랑 인프라스트럭처를 연결시켜주는 로직

흐름만 가지고 있음.(service 클래스 느낌)
어떻게 연결할 것인지를 커버.

 

 

도메인 로직이라고 하는건 POJO를 얘기한다.

테스트 어려운 코드를 배제하는것

 

 

3. 엔티티에서 도메인에 의존하는건 문제가 없음.

 

 

 

4. DDD를 도입하려고 하는 내부 개발자가 존재.

걱정이 되는데,

조직에서 도입한다고 하면 전술적패턴만 쓴다면 위험할 것 같은데

 

어떤 기준으로 생각하는게 좋을까?

애자일부터 시작해야 하지 않을까?

 

 

A : 패턴자체를 쓰는건 괜찮다고 생각하심.

걱정되는 것은 

오늘 말한건 다 적용하는것 자체가 위험함.

 

애그리게이트라는게 의미가 있으려면 불변식이 정말 잘 되어있어야 한다.

여러사람이 동시에 같은 단위로 관리가 되어야 한다.

일관성을 가지고 최종 목적으로 DDD를 사용하는게 되는게 좋지,

DDD 자체를 적용하는게 목적이 되지 않았으면 좋겠다.

우리에게 필요한 지 판단하고 써야 한다.

 

 

5. 리팩토링

실무에서 견적이 안나오는 경우

리팩토링했을때에도 문제가 나올 수 있음.

보통 통합테스트를 먼저 넣는다. 

리팩토링할때는 기능 변경과 추가를 따로 해야한다.

동시에 하면 망한다.

 

 

 

6. TDD기법연습중.

DDD에서 적용해본다면 도메인 객체 위주 단위테스트에 접목가능해보이는데

생각은?

아니면 DDD랑은 무관하다고 생각하시는지?

 

 

A: 

1. TDD는 어디든 접목 가능하다.

2. DDD에서 접목해본다고 하면 편한 개념은 애그리게이트 개념일 것이다.

 

단위테스트를 한다면

어디서 부터 해야할지결정해야 하는데,

출발점은 애그리게이트부터일 것이다.

 

 

 

 

의존성법칙

1.불안정한곳에서 안정한 곳으로,

2.단방향으로

 

 

 

 

 

 

 

 

 

 

 

출처 

  • 사이트, 검색명 (날짜)