도메인 이벤트로 어떻게 결과적 일관성을 어떻게 유지할 수 있게 되는 건지 잘 이해가 안 됐었다. 글로벌하게 트랜잭션을 유지하는 것 굉장히 어려운 주제인데, 도메인 이벤트로 뭔가 쉽게 해결할 수 있을 것만 같았다. 기존에 Two phase commit으로 해결을 할 경우에는 서로 다른 Bounded context가 의존성을 갖게 된다. 서로가 서로에게 의존하다 보면 순환 의존성이 생기게 되고 이는 유지 보수를 굉장히 어렵게 한다. 도메인 이벤트로 문제를 해결하면 이러한 의존성을 없앨 수 있다. 하지만 그렇다고해서 아무런 문제가 없는 것은 아니다. 도메인 이벤트를 구독하여 실행할 때 실패할 경우는 또 따로 해결해줘야 한다.
불변성을 사용해서 어떻게 설계를 단순하게 할 수 있는지 궁금했었다. 코드 자체가 더 줄어들거나 하는 것이 아닌 테스트가 쉬워지고 프로그램의 예측 가능성이 더 증가한다. 함수형 패러다임에서는 엔터티도 불변하게 하려고 하는데 이는 패러다임이 다른 것이다. 객체지향에서와는 조금 다른 접근 방식이어서 그렇다고 해서 엔터티가 불변하게 하는 것은 아니고 함수형 패러다임에서는 코드적으로 불변하게 작성할 뿐 엔터티가 불변하다고 정의하지는 않는다.
엔터티의 식별자를 만드는 방법이 여러 가지가 있었는데 또 하나의 바운디드 컨텍스트가 식별자를 할당하는 부분이 있었다. 책을 읽고서는 잘 이해가 안 되었었는데 식별자를 할당하는 역할만 하는 바운디드 컨텍스트가 있을 수 있다.
디렉터리 구조를 잡을 때 공유하는 값 객체 혹은 엔터티는 어디에 둘지에 대해서 고민하시는 분도 있었다. 공유되는 해당 객체 혹은 엔터티가 굉장히 중요하고, 개념이 중복되지 않아야 한다면 공유된 커널을 사용해서 다른 모듈로 분리하면 되지만 그런 것이 아니면 대부분의 경우 따로 관리하는 게 더 좋다. 디렉터리 구조는 바운디드 컨텍스트를 기준으로 잡아야 하는데 이는 책에서 상세하게 나와있는 부분이다.
책에서 나온 코드에 대해서 아무 행동도 실행하지 않는데 코드를 구현한 부분이 있엇다. 5장에 295쪽의 코드인데 객체 지향 설계에서 이런 경우 잘못된 경우라고 생각할 수 있는데 예제 코드에서는 그런 경우는 아니었다. Entity의 유효성을 검사하는데 정말 아무런 유효성을 검사하지 않는 경우 아무런 행동도 하지 않고 항상 참인 값을 반환할 것이다.
도메인 이벤트를 꼭 사용해야 하는가?에 대해서도 같이 얘기했는데 꼭 사용하지 않아도 된다. 모놀리식 애플리케이션에서는 대부분의 경우 꼭 사용할 필요가 없다. 더 복잡성만 증가시키기 때문이다. 하지만 마이크로 서비스 아키텍처에서는 선택이 아닌 필수일 수도 있다.
자바스크립트로 직접 만들면서 배우는 - 자료구조와 알고리즘 강의 바로 가기
실습으로 마스터하는 OAuth 2.0: 기본부터 보안 위험까지 - OAuth 2.0 강의 바로 가기
기계인간 이종립, 소프트웨어 개발의 지혜 - Git 강의 바로 가기
코드숨에서 매주 스터디를 진행하고 있습니다. 메일을 등록하시면 새로운 스터디가 시작될 때 알려드릴게요!
