2019-11-29 금요일

앤터프라이즈 애플리케이션 아키텍처 패턴

이 책을 처음 접한건 한창 DDD를 공부할 때였다. 뭔가 설계라는 것을 제대로 해보고 싶어서 공부하던 때였는데, 그 때엔 아무런 경험도 없었다. 그러니 이 책을 읽어도 내용이 머릿속에 들어올 리가 만무했다. 그 때 당시에는 중요한 부분이랍시고 형광펜으로 줄을 그어놨는데, 지금 와서 보니 그렇게 중요한 내용은 아니었던 부분들이 많이 눈에 띄었다.

요즘 드는 생각은, 어쨌든 개발은 문제를 해결하는 일이다. 그러면 어떤 문제를 해결하는 방법론을 공부할 때, 내가 그 문제를 경험해보지 않으면 깨달음을 얻기가 힘들다는 것이다.

이론과 실전은 다르다. 개발은 실전이다. 개발의 유명한 고전서적들은 대개 문제를 해결하는 방법론에 대한 주제가 많다. 예를 들자면 리팩토링, 클린코드, 클린 아키텍처, 최근에 읽은 오브젝트(난 이 책이 고전서적의 반열에 올라가도 된다고 생각한다) 등 이런 책들은 모두 선배 개발자분들이 오랜 시간동안 개발을 하면서 느꼈던 점들, 어떻게 하면 더 개발자들이 편-안한 개발을 할 수 있을지 그 방법에 관한 책들이다.

그렇다면 일단 선배 개발자들이 해왔던 것들을 나도 경험을 해봐야 한다. 객체지향의 이론을 공부했다면 내 생각대로 직접 개발을 해보고, 문제를 만나고, 이걸 어떻게 해결할까 고민을 해보고 이런 과정들이 선행되고 난 뒤에 이 책들을 읽으면 내가 겪은 문제들을 이미 겪은 선배 개발자들이 어떻게 해결을 했는지 조언을 듣고, 그 분들이 많은 시간을 공들여 삽질해온 결과물들을 감사히 받아들이면 되는 것이다.

그 분들이 n년이 지나고서야 얻은 깨달음들을 공짜로 얻을 순 없다. 그 깨달음을 얻고자 한다면 나도 그만큼의 시간을 투자해야 된다. 그래도 결국 나는 이득이다. 그 분들의 n년을 나는 n개월만에 얻을 수 있기 때문이다.

결론은 이렇다.

앞으로 공부하고자 하는 개발 분야가 있다면, 그 분야의 전체 맥락을 살펴본다. 그리고 바로 코딩으로 내가 몸소 경험해보자. 그 뒤 겪었던 문제들을 정리하면서 책을 읽자.

도메인 모델

• 객체지향 도메인 모델은 종종 데이터베이스 모델과 비슷해 보이기도 하지만 차이점이 많다.
• 단순 도메인 모델은 대부분의 도메인 객체가 각 데이터베이스 테이블과 일치하므로 외형상 데이터베이스 설계와 거의 비슷해 보인다.
• 리치 도메인 모델은 객체간의 협력으로 인해 데이터베이스 설계와 상당히 다르게 보인다.
  - 복잡한 논리를 나타내는 데 적합하지만 데이터베이스에 매핑하기는 더 어렵다.
• 도메인 객체는 시간이 지날수록 비대해지기 마련인데, 문제가 있을 정도로 비대해졌을 때 분리하는 것이 좋다.
  - 일찍부터 분리하면, 구현된 기능을 중복해서 구현할 여지가 생긴다.
  - 분리된 객체를 찾지 못하면 중복구현할 여지가 생긴다.
• 복잡하고 끊임없이 변하는 비즈니스 규칙을 구현해야 한다면 사용하는게 좋다.
• 단순하면 트랜잭션 스크립트가 더 나은 선택이다.