도메인 주도 설계 - 09. 암시적인 개념을 명확하게

dvmflstm·2020년 2월 16일
0
post-thumbnail

개발자들이 토의 중에 단서를 얻거나 설계상에 암시적으로 존재하는 개념을 인지하면 도메인 모델과 관련 코드를 대량으로 변환하게 되며, 그 후 하나 이상의 객체와 객체 간의 관계를 활용해 모델 내에 해당 개념을 명확하게 표현하게 된다.

개념 파헤치기

개발자는 잠재해 있는 암시적인 개념을 드러내는 단서에 민감해야 한다.

언어에 귀 기울여라

도메인 전문가가 사용하는 언어에 귀 기울여야 한다. 복잡하게 뒤얽힌 개념들을 간결하게 표현하는 용어가 있는가? 내가 선택한 단어를 적절하게 고쳐주는가? 내가 특정 문구를 이야기할 때 도메인 전문가의 얼굴에서 곤혹스러운 표정이 사라지는가? 이 모두가 바로 모델에 기여하는 개념의 실마리에 해당한다. 사용자 혹은 도메인 전문가가 설계상의 어디에도 표현돼 있지 않은 어휘를 사용하고 있다면 그것은 설계가 잘못되었다는 경고 신호다. 누락된 용어를 설계에 포함시킴으로써 ubiquitous language를 정제하고 모델과 설계를 향상시킬 수 있다.

어색한 부분을 조사하라

도메인 모델을 설계하고, 도메인 전문가와 토의하는 전 과정에서 어색한 부분이 없는지 예의주시해야 한다. 객체가 모든 작업을 원활하게 수행하지만 할당된 일부 책임이 어색하다는 것을 발견할지도 모른다. 또는 뭔가가 누락되었다는 사실을 깨닫는다고 해도 모델과 관련된 문제를 어떻게 풀어야 할지 감이 잡히지 않을 수도 있다.

이때 적극적으로 나서서 도메인 전문가가 그러한 개념을 발견할 수 있게 해야 한다. 도메인 전문가가 다양한 아이디어를 고안해서 도메인을 더 명확히 표현할 수 있을 만한 여러 가지 모델을 시도해봐야 할 것이다.

모순점에 대해 깊이 고민하라

프로그램 요구사항을 파헤칠 때 마주하게 되는 여러 가지 모순점들은 심층 모델에 이르는 중요한 단서로 활용될 수 있다. 어떤 모순은 용어를 다르게 쓰는 데서 발생할 수도 있고, 또 어떤 모순은 도메인을 잘못 이해하는 데서 발생할 수도 있다. 또한 여러 도메인 전문가가 모순되는 사실을 진술하는 경우도 있다. 존재하는 모든 모순을 해소하는 것은 현실적이지도, 바람직하지도 않지만 모순들에 대해 깊이 고민하는 과정에서 모델을 한층 심층적으로 만들 기회가 나타날 수도 있다.

SPECIFICATION (명세)

모든 어플리케이션에는 특정한 규칙을 검사하는 Boolean 테스트 메서드가 존재하기 마련이다. 검사할 규칙이 단순하다면 문제가 되지 않겠지만, 복잡한 규칙을 가진 객체의 경우 객체가 가지는 명료함이 규칙을 검사하는 코드에 묻혀 사라져 버릴 것이다.

종종 업무 규칙이 entity나 value object가 맡고 있는 책임에 맞지 않고 규칙의 다양성과 조합이 도메인 객체의 기본 의미를 압도할 때가 잇다. 그렇다고 규칙을 도메인 계층으로부터 분리해서도 안될 노릇이다. 이럴 때 업무 규칙들에 대한 검사만을 책임으로 하는 specification 객체를 만들면 도메인 객체의 본래 의미를 명료하게 유지할 수 있고, 기존에 도메인 객체 내에 암시적으로 존재했던 규칙들을 명시적으로 만들 수 있다. 명시적으로 만들어진 업무 규칙들은 도메인 모델을 더 명확하게 표현할 수 있게 될 것이다. 다음과 같은 상황에서 specification의 활용은 빛을 발할 수 있다.

  1. 객체가 어떤 요건을 충족시키거나 특정 목적으로 사용할 수 있는지 가늠하고자 객체를 검증
  2. 컬렉션 내의 객체를 선택(ex) 기한이 만료된 송장 목록을 조회)
  3. 특정한 요구사항을 만족하는 새로운 객체의 생성을 명시
profile
서울대학교 컴퓨터공학부 github.com/BaekGeunYoung

1개의 댓글

comment-user-thumbnail
2020년 2월 21일

프로젝트 경험했던 것들을 글로 정리해주셔서 너무 감사합니다
덕분에 도움 많이 받아가요!

답글 달기