09 - 유연한 설계 코드를 수정하지 않고 새로운 동작을 추가하는 방법은 컴파일 타임 의존성을 고정시키고 런타임 의존성을 변경하는 것이다. [283p] 개방 폐쇄 원칙의 핵심은 추상화에 의존하는 것이다. [284p] 객체의 생성은 피할 수 없다. 어딘가에는 객체를 생성해야한다. 객체 생성이 문제가 아니라 부적절한 곳에 객체가 생성되는 것이 문제다. 동일한 클래스에서 객체 생성과 사용이 이루어지는 것이 문제다. [287p] 팩토리 패턴으로 생성 책임을 전가하자. 생성과 사용을 분리하기 위해 객체 생성에 특화된 객체를 팩토리라고 부른다. [289p] 팩토리는 도메인 모델에 속하지 않는 순수한 기숧의 결정이다. 팩토리와 같이 도메인과 아무런 관련 없는 객체를 순수한 가공물(Pure fabrication)이라고..

05 - 책임 할당하기 객체에게 중요한 것은 데이터가 아니라 외부에 제공하는 행동이다.[134p] 책임을 결정할 땐 메시지를 결정하고 메시지를 누구에게 전송할지 찾아보아라.[135p] 책임 주도 설계의 핵심은 책임을 결정한후 책임을 수행할 객체를 결정하는 것이다.[136p] GRASP : 일반적인 책임 할당을 위한 패턴 Information expert : 메시지를 수신할 적합한 객체는 누구인가? [139p] Low coupling : 낮은 결합도 [143p] High Cohesion : 높은 응집도 [143p] Creator : 어떤 객체에게는 다른 객체를 생성할 책임을 지게해야한다. [144p] Polymorphism : 타입에따라 변하는 행동이 있다면 타입을 분리하고 변화하는 행동을 각 타입의 책임..

00 - 공통 연극 - 배우 - 배역 협력 - 역할 - 객체 설계란 코드를 배치하는 것이다. 01 - 객체 책임의 이동이 중요하다. 책임을 올바른 위치에 놓는 것만으로도 개선이 가능하다. 자신의 데이터를 스스로 처리하는 자율적인 객체를 만들어야 결합도를 낮추고 응집도를 높일 수 있다. [26p] 외부 간섭을 배제하고 메세지를 통해서만 협력하는 자율 객체를 만들어야한다. [26p] 절차 지향 => 객체가 소극적인 존재 객체 지향 => 객체가 적극적인 존재 객체를 적극적인 존재로 만드는 법 외부간섭을 줄인다. 메세지를 통해서만 협력한다. 사설) 스프링을 사용하다보니 비즈니스 로직이라는 이유로 모든 책임이 서비스 컴포넌트로 집중이되는데, 객체 지향이라는 관점에서는 좋은 설계는 아닌 듯 싶다. 02 - 객체 지..

소프트웨어 아키텍쳐의 목표 필요한 시스템을 만들고 유지보수하는데 투입 되는 인력을 최소화한다. 개발자 입장에서 전력을 기울이지 않는 개발자는 없다. 소프트웨어의 어원처럼 소프트웨어는 반드시 부드러워야한다. 구조적 프로그래밍 Goto 문이 없어진 이유: Goto 문은 재귀 호출, 구조적 분해라는 과정을 방해하는 요소 모든 프로그램은 순차 분기 반복이라는 구조로 만들 수 있다. =>프로그램에서도 유클리드 계층 구조 를 만들 수 있다. 객체 지향 프로그래밍 객체 지향의 3가지 키워드 : 캡슐화, 상속, 다형성 자바와 C# 은 헤더와 구현체 분리하는 방식을 버렸고 코드상에 어떤 멤버변수가 있는지 알게됨으로서 캡슐화이 가치가 일정 훼손되었다. 자바와 C# 에서의 상속은 C++에서도 눈속임으로 가능한 방법이었다. ..

아키텍처의 중요성 긴급한 일(변경 요청)에 밀려 중요한 일, 예를 들어 아키텍쳐를 어기거나 아키텍처 없이 개발을 시작하는 미련한 짓을 하지마라. 책에서 제시하는 우선 순위는 다음과 같다. 긴급하면서 중요한 일 중요한 일 긴급한 일 이도 저도 아닌 일 인터페이스를 사용하자. import 할 때 구체 클래스를 import 하지마라. 현실적으로 가능한가? 실제로는 시도조차 해본적이 없기 때문에 그렇게 생각하는 것 같기도하다. 다음 프로젝트에서는 적용해보는게 좋을 듯 싶다. 결합도를 낮춰라. 의존성을 낮추는 것의 목표 : 변동성의 격리 의존성을 낮추는 방법 : 순환 의존성을 없애라. [117p] class 간에 양방향 관계를 없애야한다. [78p] 롬복을 적용할 시 toString, hashCode 계산에서 스..

하드웨어 관점 CPU 하이퍼 스레딩 포함 32코어 까지 대응. 32 코어 보다 크면 너무 많은 스레드가 생성되어 OOM 이 발생한다. CPU 사용률이 60% 이상이면 CPU 확장을 고려해보는 것이 좋다. RAM 최대 32 GB. 32GM 이상이면 GC 수행시 성능 저하가 염려된다. Disk SSD 네트워크 분산 구조를 지원하므로 클러스터 관점이 더 좋다. Document 관점 Shard의 크기를 결정하는 기준 1. 데이터 노드의 갯수와 맞춘다. 가장 손쉽게 생각할 수 있는 방법. 2. CPU 코어의 갯수와 맞춘다. ES가 병렬 처리 기반이므로. 3. Document의 데이터 크기 샤드의 물리적인 크기는 50GB 이하인 것이 좋으므로. 인덱싱 처리량을 늘리는 가장 쉬운 방식이 샤드를 늘리는 것. 샤드의 크..