레이어드 아키텍처의 각 영역은 서로 다르다. 관심사가 다르고, 담겨있는 로직이 다르다. 서로 다르기 때문에 설계의 관점과 필요한 지식도 다르다. 그냥 다르다는 말로는 부족하다. 완전히 다르다거나 전혀 관련이 없다고 말해야 충분할 것 같다. 비슷하게 설계할 가능성이 크기 때문이다. 실제 개발을 하다보면, 풀고자하는 문제에만 집중해서 영역에 대한 생각을 충분하게 하지 않게 된다. 이런 일을 방지하려면, 저울을 반대쪽으로 밀어놓고 시작해야 균형이 맞는다.
오늘은 설계를 잘못한 탓에 모든 영역에서 문제가 터졌다. 가장 중요한 도메인 영역에서는 추가하려는 것이 값 객체인지 엔티티인지 명시적으로 정하지 확정하지 않은채로 작업에 들어갔다. 대략적인 생각은 있었지만, 확정해두지 않으니 논리가 계속해서 흔들렸다. 엔티티임이 자명했던 도메인 객체는 데이터를 다루는 것 처럼 처리했다. 도메인영역을 코딩할때, 도메인 영역에 대한 지식과 판단기준에 온전히 집중하지 않은 탓이었다.
프레젠테이션 계층에서는 사실 요구 사항을 달성할 수 있기만 하면 된다. 도메인이 여기에 휘둘릴 이유가 없다. 오히려 주요로직보다 프레젠테이션 계층을 적절하게 조율하는 것이 더 간단한 것 같다. 엔드포인트를 꼭 하나로 하고 인자를 추가해서 복잡성을 심화시킬 필요도 없다. 두개로 단순하게 만들어도 된다.
영속성을 처리하는 영역에서는 테이블 구조와 성능등을 생각하는 관점이 필요해진다. 식별자는 어떤 것으로 해줄 것인지, 도메인의 변경 사항이 테이블 상에서 어떻게 처리되어야 할 지에 대한 판단이 필요해진다.
쓰고 싶은 주제
- 서로 다른 영역은 설계의 관점이 서로 다르다.
- 다른 관점과 지식이 동원되어야 올바른 설계를 할 수 있다.
- 어제는 영역사이의 협력에 심취했다. 올바른 인터페이스를 통해서 서로 소통하는 것에 중점을 두었다.
- 어제는 어떤 로직이 어디에 속해야 하는지에만 신경을 썼다.
추가로 작성하고 싶은 주제
- 대가가 되기까지 아웃풋을 미루지 말자.
