일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- docker
- 서비스스펙
- 설계
- springcloud
- 단위테스트
- spring cloud netflix
- test
- dfs
- BFS
- Java
- spring cloud netflix zuul
- reactive
- java #jvm #reference #gc #strong reference
- Eureka
- container image #docker #layer #filesystem #content addressable
- 탐색
- microservice architecture
- code refactoring
- spring cloud netflix eureka
- unit
- netflix eureka
- Dynamic Routing
- unittest
- netflix
- forkandjoinpool #threadpool #jvm #async #non-blocking
- zuul
- api-gateway
- spring cloud
- Spring Data Redis
- Today
- Total
phantasmicmeans 기술 블로그
프레젠터는 험블 객체 패턴을 따른 형태로, 아키텍처 경계를 식별하고 보호하는 데 도움이 된다. 22장 '클린 아키텍처'는 험블 객체 구현체들로 가득 차 있다. 험블 객체 패턴 테스트하기 어려운 행위와 테스트하기 쉬운 행위를 분리하기 쉽게 가장 기본적인 본질은 남기고, 테스트하기 어려운 객체를 험블 객체로 옮김. 나머지 모듈에는 험블 객체에 속하지 않는, 테스트하기 쉬운 행위를 모두 옮긴다. GUI의 경우 단위 테스트가 어려움 화면을 보면서 각 요소가 필요한 위치에 적절히 표시 되었는지 검사하는 테스트는 작성하기 매우 어렵다. 하지만 GUI에서 수행하는 행위의 대다수는 쉽게 테스트할 수 있다. 험블 객체 패턴을 사용하면 두 부류의 행위를 분리해 프레젠터와 뷰 라는 서로 다른 클래스로 만들 수 있다. 프레젠..
ADP: 의존성 비순환 원칙 하향식(top-down) 설계 SDP & SAP ADP: 의존성 비순환 원칙 컴포넌트 의존성 그래프에 순환(cycle)이 있어서는 안된다 숙취 증후군 동일한 소스 파일을 수정하는 환경에서 발생. 누군가가 마지막으로 수정한 코드 때문에 정상 동작하지 않음 주 단위 빌드(Weekly build) 한 주의 첫 4일은 알아서 코딩하고 마지막 날 몰아서 통합 결국 통합 이슈를 겪게 되고 효율성 저하 순환 의존성 제거하기 개발 환경을 릴리즈 가능한 컴포넌트 단위로 분리하는 것 개발자가 해당 컴포넌트가 동작하도록 만든 후, 해당 컴포넌트를 릴리스하여 다른 개발자가 사용할 수 있도록 함 해당 컴포넌트를 사용하는 개발자들은 릴리즈 된 버전을 사용, 새 릴리즈를 사용은 각 팀에서 알아서 판단 ..
Key Point 안정된 추상에 의존시키며 구체에 의존 X 소스 코듸 의존성과 제어 흐름은 반대로 -> 이 원칙이 의존성 역전 DIP 의존성 역전 원칙에서 말하는 유연성이 극대화된 시스템이란 소스 코드 의존성이 추상에 의존하며 구체에는 의존하지 않는 시스템 자바와 같은 정적 타입 언어에서 이 말은 import 구문이 오직 인터페이스나 추상 클래스 같은 추상적인 선언만을 참조해야한다는 뜻 구체적인 대상에 절대로 의존해서는 안됨 이러한 아이디어를 규칙으로 보기에는 비현실적 측면이 있음 Java String 구체 클래스 그 예시로 자바의 String은 구체 클래스이며, 이를 추상 클래스로 만드려는 시도는 현실성이 없음. 이 경우 구체 클래스에 대한 의존성은 벗어날 수 없고, 벗어나서도 안됨 String은 매우..
기본적으로 우리는 비즈니스 도메인에 깊이 뿌리내린 모델을 만들어야한다. (핵심 개념을 매우 정확하게 반영하는 모델을 만들어야한다.) 그 다음 우리는 이 모델들을 코드로 구현하는 작업을 수행한다. 최고의 모델을 만들었음에도 코드로 적절하게 바꾸지 못하면, 결국 신뢰할 수 없는 소프트웨어가 만들어진다. 어느 도메인이든 다양한 모델로 표현되고, 각 모델들은 다양한 코드로 표현될 수 있다. 또한 특정 문제에 대한 해법도 여러가지 일 수 있다. 우리는 이중 무엇을 택할 것인가? 우리가 품게되는 근본적인 질문은 모델을 코드로 어떻게 변환할 것인가? 하는 것이다. 분석 모델 설계 기법 코드 설계와 분석을 분리하고 분석과 코드 설계를 보통 서로 다른사람이 작업하도록 한다. 분석 모델은 비즈니스 도메인 분석 결과물일 뿐..
유비쿼터스 언어 소프트웨어 전문가와 도메인 전문가가 이야기하다보면 의사소통 장벽으로 인한 근본적 어려움이 있음 도메인 전문가는 DB가 무엇인지 라이브러리가 무엇인지 알지조차 못한다. 자신의 특화된 분야만 알고있다. 외부인들이 이해하기 어려운 자신들만의 전문용어로 이야기한다. 팀 멤버끼리 도메인에 관해 토의할 수 있는 공통언어를 갖지 못하면 심각한 위험에 직면하게 된다. 우리는 모델을 이야기하고 정의할 때 같은 언어로 말할 필요가 있다. 도메인 주도 설계의 핵심 원칙은 모델 기반의 언어를 사용하는 것 > 모델은 소프트웨어와 도메인이 서로 교차하는 지점이기 때문 모델을 언어의 중추로 사용하라 이 언어를 최대한 끊임없이 사용하도록 요구하라 팀이 사용하는 모든 의사소통 형식에 항상 이 언어가 사용되도록 확인하라..