Dependency maven repository: https://mvnrepository.com/artifact/io.github.benas/random-beans 기능 객체나 콜렉션의 값을 random하게 채워서 반환한다. 테스트 데이터를 만들기 위해서 개발자가 모든 필드에 값을 채울 필요가 없다. 테스트에 꼭 필요한 필드만 값을 넣지 않고, 개발자가 직접 설정할 수 있다. 사용법 Random Object public static T random(final Class type, final String... excludedFields) example: SomeObject someObject = EnhancedRandom.random(SomeObject.class) Random Collection pub..
X-FORWARDED-FOR 란? X-Forwarded-For (XFF) 헤더는 HTTP 프록시나 로드 밸런서를 통해 웹 서버에 접속하는 클라이언트의 원 IP 주소를 식별하는 사실상의 표준 헤더다. 클라이언트와 서버 중간에서 트래픽이 프록시나 로드 밸런서를 거치면, 서버 접근 로그에는 프록시나 로드 밸런서의 IP 주소만을 담고 있다. 클라이언트의 원래 IP 주소를 보기위해 X-Forwarded-For 요청 헤더가 사용된다. Nginx nginx.conf server { ... set $xff $http_x_forwarded_for; if ($http_x_forwarded_for ~ "^(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})") { set $xff $1; } if ($xff = ..
DDD를 공부하면서 느낀 점 객체지향 5원칙이 있다. DDD는 이 5원칙을 개념적으로 더 구체화시키는 설계 기법이라고 생각되었다. "어떻게 하면 더 객체지향스럽게 만들 수 있을까?", "어떻게 하면 좀 더 의사소통을 쉽게 할 수 있을까?", "어떻게 하면 유지보수의 비용을 줄일 수 있을까?" 등등.. 결국 DDD는 프로젝트를 객체지향답게 개발하는 방법이다. SRP(단일 책임 원칙) OCP(개방-폐쇄 원칙) LSP(리스코프 치환 원칙) DIP(의존 역전 원칙) ISP(인터페이스 분리 원칙) TDD에 관해서 부정적으로 생각했었던 부분이 바뀌었다. TDD에 대해서 부정적이 었던 이유는 TDD를 도입해야 한다고 말하는 사람들 중 왜 TDD가 실패하는지에 대해서 말해주는 사람이 없었다. 내가 생각하는 TDD의 실..
1. 상호작용 - 종합적인 계획은 전체주의적인 질서를 만들어 내기 때문에 너무 경직되어 불가피하게 일어나는 자연스럽고 예측 불가능한 변화에 유연하지 못하다. 때문에 Context, Distillation, 대규모 구조를 조합하여 상호작용을 이끌어 내야 한다. - 대규모 구조와 Bounded Context와의 결합 - 대규모 구조는 1 ~ N개의 Bounded Context에 영향을 주면서 Context Map을 구성할 수 있다. - Responsibility Layer는 N개의 Bounded Context에 적용될 수 있다. - 대규모 구조는 Core Domain안의 여러 관계와 Sub Domain 사이의 관계를 설명할 수 있다. 2. 평가 일관된 Context Map을 그릴 수 있는가? Ubiquito..
큰 시스템에서 해당 시스템의 요소를 전체 설계에 걸친 패턴에서의 "역할" 측면에서 해석하게 할 수 있는 지배적인 원칙이 없다면 개발자들은 나무만 보고 숲을 보지 못한다. 우리는 전체의 세부 사항을 깊이 파고들지 않고도 전체의 각 부분이 담당하는 역할을 이해할 수 있어야 한다. 때문에 전체 시스템을 포괄하고 각 부분의 책임을 자세히 알지 못해도 전체적인 관점에서 해당 부분의 위치를 어느 정도 이해하는데 도움을 주는 규칙이나 관계의 패턴을 고안해야 한다. Evolving Order : 발전하는 질서 프로젝트에서는 다양한 방법으로 개발을 제약하는 Architecture가 적용되는데 이런 Architecture가 Application과 Doamin까지 내려간다면 해당 아키텍처만의 문제가 발생할 수 있다. 개념적..
Distillation은 혼합된 요소를 분리해서 Domain Model의 본질을 좀 더 값지고 유용한 형태로 뽑아내는 과정이다. 이 과정은 가장 중요한 Domain Model에 초점을 맞춤으로써 시스템의 전체 설계를 파악과 리펙토링, 의사결정을 돕니다. Core Domain Business Domain을 대표하는 업무와 관련된 Model을 찾고 요약한다. 가장 가치 있고 전문화된 개념을 부각해야 한다. Core Domain을 찾는 일은 반복 주기를 거치면서 발전한다. Domain Vision Statement Application이 조직에 가져올 기본 개념과 가치를 전달하는 문서를 작성한다. Domain Model의 본질에 집중하여 짧게 작성한다. 팀 내에서 방향성을 공유하게 만들어준다. 팀의 의사소통 ..
많은 Model이 사용되는 코드는 버그가 발생할 확률이 높고, 이해하기 힘들다. 이런 문제점을 개선하기 위해서 Team, Application, Database 등의 기준으로 Context를 정의하고, 해당되는 Model을 정의한다. 이 Context를 Bounded Context라고 부르며 이 Context안의 Model은 일관된 상태로 유지하고, 다른 Context의 이슈 때문에 영향을 받아서는 안된다. ** Bounded Context는 Module이 아니다. -> Moudle도 일종의 경계를 제공할 수 있기 때문에 헷갈릴 수 있지만 둘은 서로 동기가 다른 패턴이다. Module은 단일 Model 내에 포함된 요소를 구성하는 데도 사용되며, 꼭 개별 Context에 의도를 전달하는 것은 아니다. C..
많은 Over-Engineering이 유연성이라는 명목으로 정당화되어 왔다. 그러나 과도한 추상 계층과 간접 계층이 존재하면 오히려 유연성에 방해가 된다. 또한 설계 요소가 Monolithic으로 구성돼 있을 경우 코드 중복이 발생할 가능성이 높고, 각 부분을 재결합하기가 힘들어진다. 재사용성을 높이고자 Class와 Method를 분리할 수는 있지만 분할된 작은 부분들이 무슨 일을 하는지 파악하기가 어려워진다. 소프트웨어가 깔끔하게 설계돼 있지 않다면 개발자들은 엉망진창으로 꼬여버린 코드를 보는 것조차 두려워하며, 혼란을 악화시키거나 예측하지 못한 의존성 탓에 뭔가를 망가트릴지도 모르는 변경을 덜 하게 될 것이다. 이런 취약성은 리팩터링과 반복적인 정제를 방해한다. Intention Revealing I..
1. Project Structure - 회사, 팀 등 개발 목적과 규모에 따라서 틀려진다. 때문에 무조건 DDD가 좋다고 할 수 없다. 2. DDD Detail (3-2 기준) 1. Interface - 사용자나 컴퓨터 시스템에게 정보를 보여주고 사용자의 명령을 해석하는 일을 책임진다. 2. Application - 소프트웨어가 수행할 작업을 정의하고 표현력 있는 도메인 객체가 문제를 해결하게 한다. 이 계층에서 책임지는 작업은 업무상 중요하거나 다른 시스템의 응용 계층과 상호작용하는 데 필요한 것들이다. 이 계층은 얇게 유지된다. 여기에는 업무 규칙이나 지식이 포함되지 않으며, 오직 작업을 조정하고 아래에 위치한 계층에 포함된 도메인 객체에게 작업을 위임 한다. 업무 상황을 반영하는 상태가 없지만, ..
- Total
- Today
- Yesterday
- scikit-learn
- Criteria
- JPA Criteria
- guava
- Join Table
- Query DSL
- Mapping
- Registrar
- Embedded Mapping
- 복합키 Mapping
- Akka
- Spring Registrar
- @Primary
- RetryTemplate
- SmartLifecycle
- docker
- Discriminate Mapping
- spring spel
- java Equals
- Charles proxy
- Property
- JPA
- Spring JDBC Template
- Typesafe Config
- java EqualsAndHashCode
- Embeddable Mapping
- java generic
- DI
- Sprint RetryTemplate
- Spring
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |