ㄷㄷㄷ: Domain Driven Design과 적용 사례공유 / if(kakao)2022
Vložit
- čas přidán 26. 08. 2024
- Legacy Server의 포팅을 위해 Domain Driven Design을 적용하여 MSA 화 한 사례를 공유합니다.
#MSA #DDD
카카오 엔터테인먼트에서 백엔드 개발자로 일하고 있는 셜록입니다.
git blame을 열면 혹시나 제가 짠 코드일까 두근두근하면서, 레거시 서버로 고통받았던 나날과 함께 backlog를 열심히 청소하는 중입니다.
발표자료 보기
👉speakerdeck.co...
if(kakao)2022에 대한 자세한 정보는
👉 if.kakao.com
if(kakao)2022에 대한 문의는
👉 if@kakaocorp.com
#카카오 #이프카카오 #개발자컨퍼런스 #기술 #개발 #ifkakao2022
![[NHN FORWARD 22] DDD 뭣이 중헌디? 🧐](http://i.ytimg.com/vi/6w7SQ_1aJ0A/mqdefault.jpg)
![[NHN FORWARD 22] DDD 뭣이 중헌디? 🧐](/img/tr.png)
도메인 엔티티와 영속화 엔티티를 분리하는 부분에서 Mapper 쪽에 질문이 있습니다.
JPA를 사용하셨는데, 도메인 엔티티에서 JPA 엔티티로 변환하는 과정에서
매개변수가 Product 도메인 객체만 포함되는 것으로 보입니다.
Mapper 클래스에 별도의 Entity Manager가 포함되지 않는 것으로 보이고
이 경우 신규로 생성되는 엔티티 로직은 어떻게든 되겠지만, 기존의 JPA 엔티티를 불러와
도메인 엔티티로 변환 후 도메인 로직 수행 이후 다시 JPA 엔티티로 변환할 때의 처리가
궁금합니다.
기본적으로 JPA는 한번 로드한 엔티티 객체의 세션을 유지하고 있는데,
이런 엔티티에 대해 로드할 때와 동일한 Pk를 직접 입력하여 JPA 엔티티를 생성하려고 하면
이미 존재하는 세션으로 인해 에러가 발생하게 됩니다.
LoadProductPort 와 SaveProductPort의 구현체에서 참조하는 Read용 Entity와 Command용 Entity가 아예 분리되어 있다면
가능할 것 같긴한데 뭔가 아리송하네요.
DDD 개념 잡는데 도움이 많이 되네요. 용어 자체를 대충 설명하고, 아키텍쳐 설계하는 설명들이 많았는데, DDD 용어를 그대로 쓰지만, 이 용어 자체가 가지는 개념을 이해하기 쉽게 설명해주셔서, 도움이 많이 되었습니다.
카카오에서 이런 컨텐츠를 제작하고 있었군요..! 잘 보겠습니다!
전반적으로 간단하게 잘 설명을 해주신 것 같습니다. 혹시 다음에도 유사한 사례로 말씀을 해주신다면 과정에 대해서도 잘 설명을 해주신다면 많은 분들에게도 더 도움이 많이 될 것 같습니다. 기존적으로 바꾸어가는 과정을 설명해주진다면.. 어떻게 레거시의 로직을 파악했는지. 동시에 운영하면서 점차적으로 어떻게 DDD를 적용했는지를 이야기해주신다면 더 도움이 될 것 같습니다.
잘 보고 갑니다. 이런 유익한 영상 제공해 주시는 분들 정말 존경스럽고 너무 너무 감사드려요.
보다가 의문이 좀 들어서 질문을 남겨 봅니다. 답변을 기대하지 않지만 다른 분들도 생각해보는 기회가 되면 좋겠네용...
TDD와 DDD, BDD는 같은 개발 방법론이나 관심사? 목적이 좀 다르다고 생각하는데.. 때문에 꼭 하나를 선택해야 하는 것이 아니라 함께 사용할 수 있지 않을까요?
개발자오빠님 멋있어여
코드까지 사례공유 좋아요
한승님의 설명이 깔끔해서 좋았습니다 감사해요!
굳!!
ㄷㄷㄷ;
6:55에 layered와 clean architecture를 비교해주셨는데요. 둘이 다른게 맞나요? Layered란 계층을 나눴다는 의미고 clean은 presentation layer, business layer, domain layer로 나눴다는 의미고 hexagonal은 그 business layer를 또 포트로 각 역할을 분리했다는 의미로 이해했습니다.
즉, hexagonal은 clean의 한 종류고 clean은 layered의 한 종류인것으로 전 이해하고 있습니다.
이거 확인해주실 분 있나요?
@@user-yo1yx5ur2j 레이어드 아키텍쳐에 클린 아키텍쳐가 있는게 아닌가요?
제가 느끼기론 hexagonal은 clean이며 layered여서 "clean과 layered를 채택을 안했다"란 말이 틀린 말 같은데요
레이어드 아키텍처는 아키텍처의 한 종류로 단순히 계층을 나눴다는 의미로 쓰인 것이 아닌 것 같아요. 이 아키텍처는 단순하고 직관적이며 구현하기 쉬운 장점이 있지만, 계층간 의존성이 강하게 결합됩니다. 반면에 클린 아키텍처는 레이어드 아키텍처와 다른 아키텍처로 구분합니다. 이 아키텍처는 계층 구조를 사용하지만(계층 아키텍처는 아님) 의존성 역전 원칙을 적용하여 계층간의 의존성을 느슨하게 유지합니다.
제가 알기로도 클린에 헥사고날이 속하는 개념으로 알고있는데
mapToJpaEntity에서 새로운 JpaEntity를 반환한다면 Id가 Null이라 문제가 여러가지 제약조건 충돌이 생길 것 같은데 update 쿼리가 날아가게 한 방법을 알 수 있을까요?
id가 null이면 insert id가 not null이면 update
@@user-gr8zp7ft9n 아 이 부분은 알고 있는 내용인데 백그라운드 전달이 부족했던 것 같네요
Update 쿼리를 보낼려면 말씀해주신 것처럼 ID가 필요하기 때문에 Entity의 Id 생성전략이 Identity 임에도 생성자로 Id로 받아야 하는 문제가 있을 것 같습니다.
또 비슷하게 Timestamp 관련 기능들고 Hibernate에 의존하고 있어 개발자 직접 값을 주입하지 않기 때문에 Null이 들어가는 문제가 있네요 이러한 것들을 어떻게 핸들링 했는지 궁금하며, 다른 특별한 방법이 있는가 궁금하여 질문드렸습니다.
@@user-eo9ic1zf9p 그런 경우엔 유즈케이스에서 인프라스트럭처에 select 해온 데이터를 받아서 업데이트를 하는 entity를 인프라 스트럭처에 보내는 형태가 아니라 업데이트 아웃포트를 만들어서 인프라스트럭처에서 유즈케이스의 커맨드를 받아서 인프라스트럭처에서 업데이트 처리하도록 해야해요
@@user-gr8zp7ft9n 아하 그럼 만약 업데이트 관련 비즈니스 규칙 검증이 필요하다면 규칙 검증만 UseCase에서 진행하고 이후 Command를 바로 Infrastructure로 보내는 것이고 비즈니스 규칙 검증이 필요없다면 그냥 바로 Infrastructure로 보내면 되는 것으로 이해했는데 맞을까요?
@@user-eo9ic1zf9p 도메인의 invariant 도메인 로직 안에서 깨지지 않아야 하는 도메인 로직은 도메인이 담당하도록 합니다. 단 여러 도메인에 걸쳐서 유효성 확인이 필요한 경우가 있습니다. 그런 경우에는 domain service를 최종으로 업데이트 되는 객체 앞에서 수행이 되게 됩니다.