ㄷㄷㄷ: Domain Driven Design과 적용 사례공유 / if(kakao)2022

[@계폭란탄찜]

디자인 패턴인 Command 패턴 공부하다가 CQRS에 대해 공부하게 됬고, 그러면서 자연스럽게 헥사고날 아키텍처까지 보게 되다가 DDD까지 왔네요 ㅋㅋ

[@jayslog]

DDD 개념 잡는데 도움이 많이 되네요. 용어 자체를 대충 설명하고, 아키텍쳐 설계하는 설명들이 많았는데, DDD 용어를 그대로 쓰지만, 이 용어 자체가 가지는 개념을 이해하기 쉽게 설명해주셔서, 도움이 많이 되었습니다.

[@taptox]

카카오에서 이런 컨텐츠를 제작하고 있었군요..! 잘 보겠습니다!

[@nijin39]

전반적으로 간단하게 잘 설명을 해주신 것 같습니다. 혹시 다음에도 유사한 사례로 말씀을 해주신다면 과정에 대해서도 잘 설명을 해주신다면 많은 분들에게도 더 도움이 많이 될 것 같습니다. 기존적으로 바꾸어가는 과정을 설명해주진다면.. 어떻게 레거시의 로직을 파악했는지. 동시에 운영하면서 점차적으로 어떻게 DDD를 적용했는지를 이야기해주신다면 더 도움이 될 것 같습니다.

[@kingsmusician]

개발자오빠님 멋있어여

[@Ethan_Kong]

감사합니다.

[@angeldoIl]

코드까지 사례공유 좋아요

[@louishuh921]

잘 보고 갑니다. 이런 유익한 영상 제공해 주시는 분들 정말 존경스럽고 너무 너무 감사드려요.
보다가 의문이 좀 들어서 질문을 남겨 봅니다. 답변을 기대하지 않지만 다른 분들도 생각해보는 기회가 되면 좋겠네용...
TDD와 DDD, BDD는 같은 개발 방법론이나 관심사? 목적이 좀 다르다고 생각하는데.. 때문에 꼭 하나를 선택해야 하는 것이 아니라 함께 사용할 수 있지 않을까요?

[@ten-log]

한승님의 설명이 깔끔해서 좋았습니다 감사해요!

[@MaruhanPark]

6:55에 layered와 clean architecture를 비교해주셨는데요. 둘이 다른게 맞나요? Layered란 계층을 나눴다는 의미고 clean은 presentation layer, business layer, domain layer로 나눴다는 의미고 hexagonal은 그 business layer를 또 포트로 각 역할을 분리했다는 의미로 이해했습니다.
즉, hexagonal은 clean의 한 종류고 clean은 layered의 한 종류인것으로 전 이해하고 있습니다.
이거 확인해주실 분 있나요?

[@MaruhanPark]

@@이승우-z7h 레이어드 아키텍쳐에 클린 아키텍쳐가 있는게 아닌가요?
제가 느끼기론 hexagonal은 clean이며 layered여서 "clean과 layered를 채택을 안했다"란 말이 틀린 말 같은데요

[@louishuh921]

레이어드 아키텍처는 아키텍처의 한 종류로 단순히 계층을 나눴다는 의미로 쓰인 것이 아닌 것 같아요. 이 아키텍처는 단순하고 직관적이며 구현하기 쉬운 장점이 있지만, 계층간 의존성이 강하게 결합됩니다. 반면에 클린 아키텍처는 레이어드 아키텍처와 다른 아키텍처로 구분합니다. 이 아키텍처는 계층 구조를 사용하지만(계층 아키텍처는 아님) 의존성 역전 원칙을 적용하여 계층간의 의존성을 느슨하게 유지합니다.

[@staryun2671]

제가 알기로도 클린에 헥사고날이 속하는 개념으로 알고있는데

[@jsbae3364]

헥사고널은 클린아키텍처의 구현의 한 종류라고 보는 곳이 많습니다.
반면 레이어드 아키텍처는 클린아키텍처 책에서 소리치는 아키텍처 챕터에 따르자면, 무슨역할을 하는 SW인지 전혀 알려주지 않는 다른류의 아키텍처이죠.

[@euichuljung8953]

굳!!

[@축구좋아하는개발자]

mapToJpaEntity에서 새로운 JpaEntity를 반환한다면 Id가 Null이라 문제가 여러가지 제약조건 충돌이 생길 것 같은데 update 쿼리가 날아가게 한 방법을 알 수 있을까요?

[@심수현-k2z]

id가 null이면 insert id가 not null이면 update

[@축구좋아하는개발자]

​@@심수현-k2z 아 이 부분은 알고 있는 내용인데 백그라운드 전달이 부족했던 것 같네요
Update 쿼리를 보낼려면 말씀해주신 것처럼 ID가 필요하기 때문에 Entity의 Id 생성전략이 Identity 임에도 생성자로 Id로 받아야 하는 문제가 있을 것 같습니다.
또 비슷하게 Timestamp 관련 기능들고 Hibernate에 의존하고 있어 개발자 직접 값을 주입하지 않기 때문에 Null이 들어가는 문제가 있네요 이러한 것들을 어떻게 핸들링 했는지 궁금하며, 다른 특별한 방법이 있는가 궁금하여 질문드렸습니다.

[@심수현-k2z]

@@축구좋아하는개발자 그런 경우엔 유즈케이스에서 인프라스트럭처에 select 해온 데이터를 받아서 업데이트를 하는 entity를 인프라 스트럭처에 보내는 형태가 아니라 업데이트 아웃포트를 만들어서 인프라스트럭처에서 유즈케이스의 커맨드를 받아서 인프라스트럭처에서 업데이트 처리하도록 해야해요

[@축구좋아하는개발자]

@@심수현-k2z 아하 그럼 만약 업데이트 관련 비즈니스 규칙 검증이 필요하다면 규칙 검증만 UseCase에서 진행하고 이후 Command를 바로 Infrastructure로 보내는 것이고 비즈니스 규칙 검증이 필요없다면 그냥 바로 Infrastructure로 보내면 되는 것으로 이해했는데 맞을까요?

[@nijin39]

@@축구좋아하는개발자 도메인의 invariant 도메인 로직 안에서 깨지지 않아야 하는 도메인 로직은 도메인이 담당하도록 합니다. 단 여러 도메인에 걸쳐서 유효성 확인이 필요한 경우가 있습니다. 그런 경우에는 domain service를 최종으로 업데이트 되는 객체 앞에서 수행이 되게 됩니다.

[@JOY-df2oz]

ㄷㄷㄷ;