[Chapter06] 도메인 지식과 원칙의 함정

[pythonstrup]

• 원칙의 함정이 굉장히 인상적이었어요!
  • 디미터 법칙과 묻지 말고 시켜라 원칙을 맹목적으로 따랐을 때의 문제점!
• 해당 부분을 읽으면서 느낀 점은 도메인 지식을 이해하지 못했을 경우 묻지 말고 시켜라 원칙을 잘못 활용할 수 있겠다는 점입니다.
• 도메인 지식을 정확히 이해하지 못한 경우 특정 책임이 어떤 객체의 책임인지 혼동이 올 수 있다고 생각합니다.

여기서 질문!

• 여러분은 부족한 도메인 지식 때문에 객체에게 비본질적인 책임을 객체에게 할당한 경험이 있으신가요?
• 도메인 지식이 부족하다면 보통 그 지식을 파악하기 위해 시간을 얼마나 사용하시나요?

[JisuPark-dev]

1. 저는 질문을 보면서 저저번 시간에 포키가 말씀해주신 고수준, 저수준 객체가 떠올랐습니다! 저수준으로 갈수록 해당 도메인에서 변경되지 않을 정보들이 담기고 처리되어야한다고 기억합니다. 이걸 몰랐을 때는 얼핏 "얘가 처리하면 될 것 같은데"라고 하면서 푸쉬 이벤트 발생 같이 핵심적이지 않는 것도 저수준의 객체에게 할당해서 작업시켰어요.
2. 요즘은 서버로직에 버그가 생기거나, 기능을 추가해야한다면 제가 추가하는 곳의 기본적인 도메인 흐름은 파악하고 작업을 하려는 것 같아요. 읽어보다가 히스토리를 모르겠으면 반이나 에드웰한테 가서 물어보고 거의 이해가 되면 코드를 작성하는 것 같습니다. - 이렇게 하다보니깐 코드리뷰의 중요성이 더 높아지는 것도 같습니다. 서로가 짠 코드의 히스토리를 알 수 있으니깐요.

[JisuPark-dev]

포키: 로하스밀 예시를 들어보겠습니다. 초기 설계에서는 주문에 대한 상태 단계 관리랑, 배송을 위한 관리가 혼재되어 있었다. scm담당자는 결제 하고 끝이 아니란걸 알게 되었다. 담당자 입장에서 주문의 상태 관리랑, 배송 관리랑 다르다는 것을 알게 되었다.

주문의 책임이 너무 많아진다. 배송에 대한 로직이 바뀌어도, 주문 로직이 바뀐다.

[JisuPark-dev]

포키 : 2. 도메인 생각하는 시간을 많이 쓴다. 처음부터 인간 정책서>?처럼 다 알아야 하겠다는 건 아니지만 왜 해야하는지, 어떤 맥락에서 이걸 짜는지 알아야 손이 나가는 편이다. 구현을 하면서도 생각하는 것 같다. 구현이랑 도메인 요구사항에 대한 고민이 같이 가는 것 같다.

[JisuPark-dev]

포키 : 개발자는 우리가 속한 도메인 안의 문제 해결을 소프트웨어로 하는 것이다. 코드 외적인 방법으로도 할 수 있다면 코드 한 줄 쓰는 것 만큼 중요하다고 생각한다.