언급하셨다시피, DDD의 진정한 힘은 유비쿼터스언어와 바운디드컨텍스트부터 시작합니다. 유비쿼터스언어를 반영해야 전술적 설계가 의미가 있는 셈이죠. OO에 근간하지만 OO 원칙을 정면으로 위배하는 패턴도 몇 있어요. 예를 들어, ID를 이용해서 애그리거트 간 디커플링을 시킨다든지, Domain Service는 행동을 객체에서 의도적으로 분리시키는 패턴이 OO와는 다른 개념입니다. Value 타입을 사용하는 것을 권장하는 등 저는 DDD의 전술적 설계가 순수OO보다 더 적용하기 심플한 측면이 있다고 개인적으로 생각해요.
자바 진영 개발자들이 DDD를 만병통치약처럼 파는 (특히 한국)경향이 있긴 하죠 ㅎㅎ. 약간 첨언하자면, DDD도 애그리거트라는 개념이 영속 단위로 트랜잭션 개념을 다루고 있고, 레포지토리 패턴은 DDD 외에서도 자주 사용되는데 저장소(DB의 스키마와 업데이트 로직)을 캡슐화하는 계층아키텍처의 역할을 합니다. 추가로 DDD로 애그리거트 설계하는게 MSA 서비스 단위 도출하는거랑 잘맞아서 쓰기도 합니다. 과대포장된 OOP라는건 동의합니다 ㅎ 시중에 나와있는 한글 책들도 사실 스프링부트 책이고, 반버논이나 에릭에반스 책도 설명이 애매한것 같습니다. 전술적 설계의 각 컴포넌트가 이런 역할을 한다 정도로 이해하는게 좋을듯요 ㅎ. 좋은 영상 감사합니다.
언급하셨다시피, DDD의 진정한 힘은 유비쿼터스언어와 바운디드컨텍스트부터 시작합니다. 유비쿼터스언어를 반영해야 전술적 설계가 의미가 있는 셈이죠. OO에 근간하지만 OO 원칙을 정면으로 위배하는 패턴도 몇 있어요. 예를 들어, ID를 이용해서 애그리거트 간 디커플링을 시킨다든지, Domain Service는 행동을 객체에서 의도적으로 분리시키는 패턴이 OO와는 다른 개념입니다. Value 타입을 사용하는 것을 권장하는 등 저는 DDD의 전술적 설계가 순수OO보다 더 적용하기 심플한 측면이 있다고 개인적으로 생각해요.
😀
자바 진영 개발자들이 DDD를 만병통치약처럼 파는 (특히 한국)경향이 있긴 하죠 ㅎㅎ. 약간 첨언하자면, DDD도 애그리거트라는 개념이 영속 단위로 트랜잭션 개념을 다루고 있고, 레포지토리 패턴은 DDD 외에서도 자주 사용되는데 저장소(DB의 스키마와 업데이트 로직)을 캡슐화하는 계층아키텍처의 역할을 합니다. 추가로 DDD로 애그리거트 설계하는게 MSA 서비스 단위 도출하는거랑 잘맞아서 쓰기도 합니다. 과대포장된 OOP라는건 동의합니다 ㅎ 시중에 나와있는 한글 책들도 사실 스프링부트 책이고, 반버논이나 에릭에반스 책도 설명이 애매한것 같습니다. 전술적 설계의 각 컴포넌트가 이런 역할을 한다 정도로 이해하는게 좋을듯요 ㅎ. 좋은 영상 감사합니다.
마이크로서비스랑 도메인 드리븐이랑 레이어링이랑 디비랑 한꺼번에 다 이야기 하려는 듯 하네요. 서로 관계 있는 부분도 있고 아닌 부분도 있는데 너무 묶어서 생각하는게 아닌가... 그렇게 공감가는 이야기는 아닌 거 같네요 :)
EMR, EHR이 생각 나는군요. HL7v3에 대해 봐야 하는 일이 있었는데...
대 놓고 Object Oriented를 사용한다고 하더라구요. 사실 이건 서비스 자체에 대한 디자인이라기보다는, 지능형 데이터 베이스 지원을 목적으로 한 전산 기록물 표준이었죠.
제가 생각하는 부분은 도메인 드리븐 디자인이 복잡성을 관리하는 부분에 특화된 것 같습니다. OOP를 좀 더 실무에 가깝게 현실적으로 접근하는 방법을 알려주는 교과서 같은 느낌이었습니다
이세상 아래 새로운건 없습니다만 ddd를 통해 배운점은 많네요 MSA 를 할때도 많은 영감을 얻었습니다~
DDD 개념과 정의, 나온 이유, 실제 적용 패턴까지 짧은시간에 압축해서 정리해주시네요.
책까지도 필요가 없는게 김포프님이 말씀해주신게 전부라고 봐도 무방한 것 같아요. 왠만한 강좌보다도 나은 것 같습니다.
18:30 결론!
저는 ddd는 도메인 지식을 코딩 내에서 표현하기 위해 만들어진것같더라고요
좋은 강의 감사합니다!
포프님 피부가 점점 좋아지시네요~~ 부럽습니다 ㅠㅠ
잘 봤습니다…..