11장 시스템

도시를 세운다면?

도시가 잘 돌아갈 수 있는 이유 중 하나는 적절한 추상화와 모듈화이다. 큰 그림을 이해하지 못할지라도 개인과 개인이 관리하는 구성요소는 효율적으로 돌아간다.

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

소프트웨어 시스템은 (애플리케이션 객체를 제작하고 의존성을 서로 '연결'하는 준비 과정과 (준비과정 이후에 이어지는) 런타임 로직을 분리해야 한다.)

Main 분리
시스템 생성과 시스템 사용을 분리하는 한 가지 방법.
생성과 관련한 코드는 모두 main이나 main이 호출하는 모듈로 옮긴다. 즉 애플리케이션은 객체가 생성되는 과정을 전혀 모른다.

팩토리
객체 생성 시즘을 애플리케이션이 결정해야 할 때 Abstract Factory 패턴을 사용하여 생성 코드를 감춘다.

ABstract Factory 패턴: 구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 패턴

의존성 주입
의존성 주입은 제어 역전 기법을 의존성 관리에 적용한 매커니즘이다. 제어 역전은 한 객체가 맡은 보조 책임을 새로운 객체에게 떠넘긴다. 새로운 객체는 넘겨받은 책임만 맡으므로 단일 책임 원칙을 지키게 된다.

확장

우리는 오늘 주어진 사용자 스토리에 맞춰 시스템을 구현해야 한다. 내일은 새로운 스토리에 맞춰 시스템을 조정하고 확장하면 된다. TDD,리팩터링, 깨끗한 코드는 코드 수준의 시스템을 조정하고 확장하기 쉽게 만든다.

반면 소프트웨어 시스템의 발전을 쉽게 만드는 건 관심사의 적절한 분리이다.

횡단 관심사
AOP: 관점 지향 프로그래밍: 코드를 횡단 관심사로 분류해 관점으로 관리하는 방법.

관점 분리 방식에는 3가지가 있다.

• 자바 프록시: 단순환 상황에 좋음. 코드를 프록시로 감싸서 구현
• 순수 자바 AOP 프레임워크: 프레임워크 사용해 내부적으로 프록시 사용
• AspectJ 관점: AspectJ 언어를 사용

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

🔎POJO(Plain Old Java Object): 오래된 방식의 간단한 자바 오브젝트

애플리케이션 도메인 돈리를 POJO로 작성할 수 있다면(=코드 수준에서 아키텍처 관심사를 분리할 수 있다면), 테스트 주도 아키텍처 구축이 가능해진다.

의사 결정을 최적화하라

우리는 때때로 가능한마지막 순간까지 결정을 미루는 방법이 최선이라는 사실을 까먹곤 한다. 최대한 정보를 모아 최선의 결정을 내리기 위해선 결정을 미루는 게 좋다.

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

아주 과장되게 포장된 표준에 집착하다가 고객 가치가 뒷전으로 밀려날 수 있다. 어떤 표준은 원래 표준을 제정한 목적을 잊어버리기도 한다.

시스템은 도메인 특화 언어가 필요하다.

🔎DSL(Domain Specific Language):특정한 도메인을 적용하는데 특화된 컴퓨터 언어. 어느 도메인에서나 적용 가능한 범용 언어와는 반대되는 개념이다.

효과적으로 사용한다면 DSL은 추상화 수준을 코드 관용구나 디자인 패턴 이상으로 끌어올린다. 그래서 개발자가 적절한 추상화 수준에서 코드 의도를 표현 할 수 있다.