Official-Dev. blog

Top-down / Bottom-up DP(Dynamic Programming) 방식은 크게 두 가지로 나뉜다. Top-down 방식과 Bottom-up 방식이다. 두 방법 모두 큰 문제를 여러 개의 부분 문제들로 나누어 푸는 방식인데 아래의 차이가 있다. - Top-down 방식은 가장 큰 문제를 방문한 후 작은 문제를 호출하여 답을 찾는 방식이다. - Bottom-up 방식은 가장 작은 문제들부터 답을 구해가며 전체 문제의 답을 찾는 방식이다. 일반적으로 Top-down은 재귀 호출을 Bottom-up은 반복문을 이용하여 구현한다. 피보나치 문제의 구현하는 예시를 살펴보자. Top-down 아래는 Top-down 방식의 예시이다. int fibonacci(int n) { if (n == 0) retu..

창발성(Emergence) 창발 현상이란 단순한 결합이 의도와 관계 없이 어떠한 결과를 나타나는 현상을 의미한다. 가령, 붉은악마 신드롬은 정부나 월드컵조직위원회가 특정한 계획에 따라 조직한 것이 아니라, 국민들이 인터넷과 방송매체, 주변과의 접촉 등을 통해 자발적으로 상호작용을 일으키며 나타난 현상이다. 아래 켄트 벡이 제시하는 단순한 설계 규칙 네 가지를 따르면 소프트웨어 설계 품질을 크게 높여주는 결과가 발생한다고 믿는다. 모든 테스트를 실행한다. 중복을 없앤다. 프로그래머 의도를 표현한다. 클래스와 메서드 수를 최소로 줄인다. 위 목록은 중요도 순이다. 모든 테스트를 실행하라. 모든 설계는 의도한 대로 돌아가는 시스템을 내놓아야 한다. 문서로는 시스템을 완벽하게 설계했지만, 시스템이 의도한 대로 ..

도메인 용어 코드를 작성할 때 도메인에서 사용하는 용어는 매우 중요하다. 쇼핑몰 프로젝트에서 레거시한 DB 구조를 가지고 있다고 가정하자. Order 테이블에는 status라는 컬럼이 있다. status 컬럼에는 "STEP1", "STEP2", "STEP3"... ,"STEP6" 이라는 정보가 저장된다. 해당 코드를 Enum으로 다음과 같이 작성할 수 있다. public Enum OrderStatus { STEP1, STEP2, STEP3, STEP4, STEP5, STEP6 } 실제 주문 상태는 ‘결제대기중’, ‘상품준비중’, ‘출고완료됨’, ‘배송중’, ‘배송완료’, '주문 취소'인데 기존의 DB에서 전체 상태를 6단계로 본 구조를 그대로 엔터티 속성으로 표현한 것이다. 해당 프로젝트를 맡은 작업자는..

엔터티와 밸류 도출한 도메인 모델은 크게 엔터티(Entity)와 밸류(Value)로 구분할 수 있다. 주문 도메인에서 만든 모델은 다음과 같다. 엔터티도 존재하고 밸류도 존재한다. 엔터티와 밸류를 제대로 구분해야 도메인을 올바르게 설계하고 구현할 수 있기에 이 둘의 차이를 명확하게 이해하는 것은 도메인을 구현하는 데 있어 중요하다. 엔터티 엔터티의 가장 큰 특징은 식별자를 가진다는 것이다. 식별자는 엔티티의 객체마다 고유해서 각 엔티티는 서로 다른 식별자를 갖는다. 주문 도메인에서 각 주문은 주문번호를 갖는데 이 주문번호는 각 주문마다 서로 다르다. 따라서 주문번호가 주문의 식별자가 된다. 주문 도메인 모델에서 주문에 해당하는 클래스가 Order이므로 Order가 엔티티가 되며 주문번호를 속성으로 갖게 ..

도메인 개발자 입장에서 온라인 서점은 구현해야 할 소프트웨어의 대상이 된다. 온라인 서점 소프트웨어는 온라인으로 책을 판매하는 데 필요한 상품조회, 구매, 결제, 배송 추적 등의 기능을 제공해야 한다. 이때, '온라인 서점'은 소프트웨어로 해결하고자 하는 문제 영역, 즉 도메인(domain)에 해당한다. 한 도메인은 다시 하위 도메인으로 나눌 수 있다. 예를 들어 다음 그림은 온라인 서점 도메인을 몇 개의 하위 도메인으로 나타낸 것이다. 카탈로그 하위 도메인은 고객에게 구매할 수 있는 상품 목록을 제공하고, 주문 하위 도메인은 고객의 주문을 처리한다. 혜택 하위 도메인은 쿠폰이나 특별 할인과 같은 서비스를 제공한다. 한 하위 도메인은 다른 하위 도메인과 연동하여 완전한 기능을 제공하게 된다. 특정 도메인..

LazyConnectionDataSourceProxy Spring은 트랜잭션에 진입하면 즉시 미리 DataSource의 커넥션을 가져온다. 가령 ServiceLayer Method에 @Transactional이 걸려있다고 가정하자. 쿼리를 날리기 전에 여러가지 복잡한 작업이 있을 수 있다. 그런데 Spring에서는 @Transactional에 진입한 순간 바로 커넥션을 걸어버린다. 이런 방식은 여러 단점이 있다. Ehcache같은 캐시를 사용하는 경우 실제 DB에 접근하지 않지만 불필요한 커넥션을 점유 JPA의 영속성 컨텍스트에서 엔터티가 존재함에도 불필요한 커넥션을 점유 Dynamic DataSource 환경에서 DataSource도 정해지지 않았는데 트랜잭션에 진입하면서 에러 터짐 커넥션 점유시간이 ..

다중 데이터 소스다중 데이터 소스 환경에서 Transaction과 Querydsl을 사용하는 방법에 대해 알아보자.먼저 데이터소스부터 보자.@Configuration@EnableJpaRepositories( basePackageClasses = { OrderRepository.class }, entityManagerFactoryRef = "masterEntityManagerFactory", transactionManagerRef = "masterTransactionManager")@EnableTransactionManagementpublic class MasterDatasourceConfiguration { @Autowired private Environment env; ..

애노테이션(Annotation) 자바 개발을 하다 보면 클래스 또는 메서드 또는 변수 앞에 @Override 같은 표시를 많이 본다. Spring처럼 각종 프레임워크나 라이브러리도 애노테이션을 많이 활용한다. 애노테이션은 메타 데이터(데이터에 대한 설명을 하기 위한 데이터)의 역할을 주로 한다. 애노테이션은 내부적으로 어떻게 동작할까? 구현하면 어떤 문제를 해결할 수 있을까? 에 대해 알아보자. Java에서 제공하는 애노테이션 종류 예를 위해 자바에서 제공하는 애노테이션을 살펴보자. 주로 해당 데이터를 설명하기 위해서 사용한다. 1. @Override 선언한 메서드가 오버라이드 되었다는 것을 나타낸다. 상위(부모) 클래스(또는 인터페이스)에서 해당 메서드를 찾을 수 없다면 컴파일 에러를 발생한다. 2. ..

예시. 티켓 판매 어플리케이션 시나리오: 소극장에서 이벤트를 통해 초대장을 분배하고 초대장이 있는 사람은 초대장을 티켓으로 교환한 후에 입장하고, 초대장이 없는 사람은 입장권을 구매한 뒤 입장한다. 구현한 클래스 다이어그램은 다음과 같다. 먼저 이벤트 당첨자에게 발송되는 초대장을 구현하는 것으로 시작하자. 초대장(Invitation)은 공연을 관람할 수 있는 초대일자(when)을 인스턴스 변수로 포함하는 간단한 클래스다. public class Invitation { private LocalDateTime when; } 공연을 관람하기 원하는 모든 사람은 티켓을 소지하고 있어야만 한다. Ticket 클래스를 추가하자. public class Ticket { private Long fee; public L..

카프카(Kafka)란? 카프카(Kafka)는 Pub-Sub 모델의 메시지 큐의 한 종류이다. 2011년 미국 링크드인(Linkedin)에서 개발했다. 더 자세히 살펴보자. 다음은 카프카 개발 전 링크드인의 데이터 처리 시스템이다. 기존 링크드인의 데이터 처리 시스템은 각 파이프라인이 파편화되고 시스템 복잡도가 높아서 새로운 시스템을 확장하기 어려웠다. 이로 인해 새로운 시스템의 개발 필요성이 높아졌고, 다음과 같은 목표를 가지고 새로운 시스템을 개발했다. 프로듀서와 컨슈머의 분리 메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에게 적용 높은 처리량을 위한 메시지 최적화 트래픽 증가에 따른 스케일아웃이 가능한 시스템 다음은 카프카를 적용한 후 링크드인의 데이터 처리 시스템이다. 한 눈에 보기에도 훨..