시스템

제작(construction)은 사용(use)과 아주 다름
소프트웨어 시스템은 (애플리케이션 객체를 제작하고 의존성을 서로 ‘연결’하는) 준비 과정과 (준비 과정 이후에 이어지는) 런타임 로직을 분리해야 한다.
관심사 분리
체계적이고 탄탄한 시스템을 만들고 싶다면 흔히 쓰는 좀스럽고 손쉬운 기법으로 모듈성을 깨서는 절대로 안 된다. 객체를 생성하거나 의존성을 연결할때도 마찬가지다. 설정 논리는 일반 실행 논리와 분리해야 모듈성이 높아진다. 또한 주요 의존성을 해소하기 위한 방식, 즉 전반적이며 일관적인 방식도 필요하다.
Main 분리
- 애플리케이션이 메인이나 객체가 생성되는 과정을 전혀 모름
- 생성과 관련한 코드는 모두 main이나 main이 호출하는 모듈로
- 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정
팩토리
- 객체 생성 시점을 애플리케이션이 결정해야할 때 -> 추상화 팩토리를 사용
- 시점은 애플리케이션에게 주지만 생성 코드는 애플리케이션이 가지고 있지 않게 함
의존성 주입..(?)
관심사 분리 예시
- graphQL을 통해서 해당 컴포넌트에 필요한 데이터만 보내준다.
  - main 페이지
  - main에 속해있는 article component

‘처음부터 올바르게’ 시스템을 만들 수 있다는 믿음은 미신이다. 대신에 우리는 오늘 주어진 사용자 스토리에 맞춰 시스템을 구현해야 한다. 내일은 새로운 스토리에 맞춰 시스템을 조정하고 확장하면 된다.
TDD, 리팩터링, 깨끗한 코드는 코드 수준에서 시스템을 조정하고 확장하기 쉽게 만듬
처음부터 완벽한 시스템은 기획, 디자인, 개발에서도 기대할 수 없는 것 같음. 특히 개발은 기획에게 완벽하게 기획하기를 바라지 말고, 디자인에게도 확장이 가능한 디자인이 나올 수 있도록 대화를 많이 해아하는 듯.

코드 수준에서 아키텍쳐 관심사를 분리하면 테스스 주도 시스템 아키텍쳐 구축이 가능해짐
최선의 시스템 구조는 각기 POJO (또는 다른) 객체로 구현되는 모듈화된 관심사 영역(도메인)으로 구성된다. 이러헥 서로 다른 영역은 해당 영역 코드에 최소한의 영향을 미치는 관점이나 유사한 도구를 사용해 통합합ㄴ다. 이런 구조 역시 코드와 마찬가지로 테스트 주도 기법을 적용할 수 있다.

참고