우테코, 사다리 게임 피드백

도메인을 설계할 때의 접근 방식

out in 방식

가장 큰 방식에서부터 접근하여 코드를 작성한다. 이 경우에는 도메인 지식이 없거나 요구사항을 객체로 도출할 수 없는 경우에 적합하다.

 

in - out 방식

작은 단위의 도메인부터 파악하여 도메인 지식이 있거나 요구사항을 객체로 도출할 수 있는 경우에 적합하다.

 

요구사항을 처음에 봤을 때에는 큰 그림으로 이를 받아들일 수 밖에 없다. 이러한 경우에는 out-in 방식으로 접근을 해야한다. 만약 요구사항을 보고 작은 도메인으로 추출 가능하다면 in-out 방식으로 접근하면 된다.

 

TDD를 사용하고자 한다면 out-in으로 구현하기가 매우 어렵다. 도메인으로 접근을 하기 어렵기 때문에 테스트를 작성하기가 쉽지 않기 때문이다.

 

 

 

작은 도메인을 찾아내기

직관에 의존 -> 한계가 명확

 

도메인을 설계할 때의 크루들은?

Out in으로 삽질하는 과정에서 찾은 것 같습니다
inputView에서 들어오는 값을 어떻게 저장할지 고민해본다
서로 이어지지 않는 부분에 대해서 생각했습니다
기능적인 관점으로 도메인을 생각했습니다
내가 컴퓨터였다면 어떻게 흐름을 진행할까?를 생각했습니다.
필요한 객체가 무엇이 있을지 정리했습니다
가장 핵심적인 객체가 뭘까를 생각했습니다

 

 

작은 도메인으로 나누기 위한 팁

일단 out-in으로 할 수 있을 만큼 접근해본다. 혹은 의존성이 없는 객체부터 찾아서 시작한다면 작은 도메인부터 찾아내는데 도움이 된다.

 

만약 TDD를 하다가 더 작은 도메인을 찾게 된 경우에는 작은 단위 개발을 바로 시작하고, 이전에 작성한 큰 도메인은 지우는 것이 좋다. 만약 이전에 작성한 큰 도메인들을 남겨두는 경우에는 작은 도메인을 구현할 때 더 큰 도메인에 대해 생각하게 된다. 작은 단위를 설계할 때 외부의 기준으로 설계하는 것은 별로 좋지 못하다.

 

작은 도메인은 그 자체로 객체스럽게 정의되어야한다.

 

하지만 만약 코드의 수정이 많이 없고 리팩토링 관점에서 도메인을 더 잘게 쪼갠다면 이전 코드를 삭제할 필요가 없을 수 있다. 반대로 도메인을 쪼개다가 다른 객체가 필요하고 수정되는 범위가 크다면 이전 코드를 삭제하는 것이 더 좋을 수 있다. 다시 말해 도메인을 쪼개는 과정에서 영향을 주는 범위를 고려해볼 수 있다. 

 

 

객체로 분리한다면 단순히 값을 증가시켜주거나 줄이는 과정도 역할로 넘겨줄 수 있게 된다.

step + 1 -> increase()

 

 

리팩토링을 할 때 가장 중요한 점 중 하나는 테스트 코드가 깨지지 않는 상태에서 이를 처리하는 것이다. 다시 말해 기존 코드를 그대로 놔두고 처리하는 것이다.