11. 시스템

시스템 제작과 시스템 사용을 분리하라

제작과 사용은 다르다.

체계적이고 탄탄한 시스템을 만들고 싶다면 흔히 쓰는 손쉬운 기법으로 무듈성을 깨서는 안된다.

설정 논리는 일반 실행 논리와 분리해야 모듈성이 높아진다.

Main 분리

시스템 생성과 시스템 사용을 분리하는 한 가지 방법으로,

생성과 관련한 코드는 모두 main 이나 main 이 호출하는 모듈로 옮기고,

나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정한다.

팩토리

때로는 객체가 생성되는 시점을 애플리케이션이 결정할 필요도 생긴다.

이럴 때는 추상 팩토리 패턴을 사용하여 결정은 애플리케이션이 하지만, 생성 코드는 애플리케이션이 모르게 할 수 있다.

의존성 주입

제어의 역전(IoC) 기법을 사용하는데,

한 객체가 맡은 보조 책임을 새로운 객체에게 전적으로 떠넘기는 것.

새로운 객체는 넘겨받은 책임만 맡으므로 단일 책임 원칙을 지키게 된다.

확장

처음부터 확장을 생각하여 들어가는 비용을 정당화하긴 어렵다.

(시골에 확장성을 고려해 처음부터 6차선 도로를 만든다면…??)

‘처음부터 올바르게’ 시스템을 만들 수 있다는 믿음은 미신이다.

오늘은 주어진 사용자의 스토리에 맞게 구현을 하고, 내일은 새로운 스토리에 맞춰 조정하고 확장한다.

횡단(cross-cutting) 관심사

EJB2 아키텍처는 일부 영역에서 관심사를 거의 완벽하게 분리한다.

예를 들어 트랜잭션, 보안, 일부 영속적인 동작은 소스 코드가 아닌 배치 기술자에서 정의,

영속성과 같은 관심사는 애플리케이션의 자연스럽게 객체 경계를 넘나든다.

자바 프록시

자바 프록시는 단순한 상황에 적합, 개별 객체나 클래스에서 메서드 호출을 감싸는 경우가 좋은 예.

AspectJ 관점

관심사를 관점을 분리하는 가장 강력한 도구는 AspectJ 언어이다.

AspectJ는 언어 차원에서 관점을 모듈화 구성으로 지원하는 자바 언어 확장이다.

테스트 주도 시스템 아키텍처 구축

애플리케이션 도메인 논리를 POJO 로 작성할 수 있다면,

즉 코드 수준에서 아키텍처 관심사를 분리할 수 있다면, 진정한 테스트 주도 아키텍처 구축이 가능해진다.

프로젝트를 시작할 때는 일반적인 범위, 목표, 일정은 물론이고 결과로 내놓을 시스템의 일반적인 구조도 생각해야 한다.

하지만 변하는 환경에 대처해 진로를 변경할 능력도 반드시 유지해야 한다.

최선의 시스템 구조는 각기 POJO 객체로 구현되는 모듈화된 관심사 영역(도메인) 으로 구성된다.

이렇게 서로 다른 영역을 해당 영역 코드에 최소한의 영향을 미치는 관점이나 유사한 도구를 사용해 통합한다.

이런 구조 역시 코드와 마찬가지로 테스트 주도 기법을 적용할 수 있다.

의사 결정을 최적화하라

가능한 마지막 순간까지 결정을 미루는 방법이 최선이다.

최대한 정보를 모아 최선의 결정을 내리기 위함

명백한 가치가 있을 때 표준을 현명하게 사용하라

표준을 사용하면 재사용성이 증가하고, 캡슐화 하기 쉽다는 장점이 있겠지만,

때로는 표준을 만드는 시간이 너무 오래 걸리는 (배보다 배꼽이 더 큰) 케이스도 있다.

결론

시스템은 깨끗해야된다. 그렇지 못한 시스템은 도메인 논리를 흐리며 기민성을 떨어뜨린다.

시스템을 설계하든 개별 모듈을 설계하든, 실제로 돌아가는 가장 단순한 수단을 사용해야 한다는 사실을 명심하자.

사견을 덧붙이면…?

음… 이번 챕터는 굉장히 자바스럽다. 아니, 스프링 스럽다? 라고 해야하나?

뭐하튼, 그렇다. 깨끗한 구조를 설명하고 있긴 하지만, 마치 스프링의 역사를 보는 느낌? (EJB1,2,3 에 대한 얘기가 나오고, 스프링 프레임워크의 등장에 대한 얘기가 나온다.)

그런 느낌으로 읽었다. 내가 스프링 개념이 빈약해서 그런지..(..) 쉽게 이해가 안되는 부분도 있고, 쉽게 읽히지는 않았다.

중간에 보면 확장 에 관련된 얘기가 나온다. 이 부분에 관해서인데,

이전에 사수가 있었을 때, 서로 추구랄까? 스타일이랄까? 그런게 꽤 달랐다.

사수는 빨리 만들고 빨리 버리자 (일종의 빠른 프로토 타이핑으로 일단 만들고 돌려봐서 확장을 고려하자) 였고,

난 기능을 만들되 최대한 확장성을 고려하여 진행하자. 였다.

그러다보니 속도? 그런 건 말할 것도 없고 ㅋㅋㅋㅋ, 그 후 사수랑 얘기를 하는데, 본인도 처음에는 나와 비슷한 스타일이었다고 한다.

그런데 기획이 하도 바뀌니까 빨리 대충 만들고, 리펙토링을 중점으로 하게 되었다고…

근데 요즘 보면 이 말이 참 맞는 것 같다. 기획이 참 잘 바뀌여… 에자일도 아닌데 말이지..