마디니블로그

리팩터링 리팩터링이란, 기능을 변경하지 않고 코드의 가독성과 유지보수가 쉽도록 코드를 변경 하는 것 리팩터링을 왜 해야 하는가 코드를 더 빠르게 만들기 위해 더 작은 코드를 만들기 위해 코드를 더 일반적이고 재사용 가능하게 만들기 위해 "코드의 가독성을 높이고 유지보수를 용이하게 하기위해 리팩터링이 필요하다." 리팩터링 구성요소 스킬(Skill): 어떤 코드가 잘못되었는지 아는 능력 문화(Culture): 리팩터링에 시간을 들이는 것을 권장하는 문화와 절차가 필요 도구(Tools): 작업의 안정성을 보장할 무언가,,, 자동화된 테스트(도구) 스킬: 무엇을 리팩터링 할 것인가? 코드 스멜을 알아 차리는 방법 -> 쉽게 이해되고 쉽게 적용할 수 있는 규칙이 필요 예) 함수는 하나의 기능을 수행해야 한다. -..

Java에서 사용하는 날짜/시간 타입인 LocalDateTime 과 Date 타입의 다양한 표현방식 예제입니다. 예제코드 출력값 LocalDateTime(Java8 이상) 의  format pattern 예제 dateTime.format(DateTimeFormatter.ofPattern("yyyy-M-dd"); 2023-5-23 dateTime.format(DateTimeFormatter.ofPattern("yyyy-MM-dd"); 2023-05-23 dateTime.format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"); 2023-05-23 21:01:55 dateTime.format(DateTimeFormatter.ofPattern("yyyy-MM-d..

CQRS 여러 애그리거트의 데이터가 필요한 조회 기능을 개발 할 때 조회 속도 개선과 함께 구현 방법에 대한 고민이 많아진다. 식별자 참조, 직접참조 등.. 객체 지향으로 도메인 모델을 구현할 때 주로 사용하는 (JPA와 같은)ORM 기법은 도메인 상태 변경 기능을 구현하는 데는 적합하지만 여러 애그리거트에서 데이터를 가져올 때는 고려할 게 많아 구현을 복잡하게 한다. 도메인 모델 관점에서 상태 변경 기능은 주로 한 애그리거트의 상태를 변경한다. 조회 기능은 애그리거트가 두 개 이상 필요할 때가 많다. 단일 모델로 두 기능을 구현 하면 불필요하게 복잡해진다. CQRS 는 상태를 변경하는 명령을 위한 모델과 상태를 제공하는 조회를 위한 모델을 분리하는 패턴이다. 각 모델에 맞는 구현 기술을 선택할 수 있다..

이벤트의 용도와 장점 구매를 취소할 때 다음과 같이 주문 도메인 클래스에서 주문 상태를 변경하고, 환불 서비스를 주입받아 환불 처리를 한다. (결제 시스템은 외부에 존재하므로 환불 서비스는 외부 결제 시스템이 제공하는 환불 서비스를 호출한다.) public class Order { // 외부 서비스를 실행하기 위해 도메인 서비스를 파라미터로 전달 받음 public void cancel(RefundService refundService) { // 주문 로직 verifyNotYetShipped(); this.state = OrderState.CANCELED; this.refundStatus = State.REFUND_STARTED; // 결제 로직 try { refundService.refund(getPay..

바운디드 컨텍스트 도메인 모델을 표현할 때 하위 도메인마다 같은 용어라도 의미가 다르고 같은 대상이라도 지칭하는 용어가 다를 수 있다. 한 개의 모델로 모든 하위 도메인을 표현하기 어렵다. 하위 도메인마다 모델을 만들어야 한다. 각 모델은 명시적으로 구분지어 섞이지 않도록 한다. [바운디드컨텍스트(BoundedContext)란] 모델은 특정한 컨텍스트 아래서 완전한 의미를 갖는데, 이때 구분되는 경계를 갖는 컨텍스트를 바운디드 컨텍스트(Bounded Context)라고 한다. 사용자에게 기능을 제공하는 물리적 시스템 모델의 경계를 결정, 한개의 바운디드 컨텍스트는 한개의 논리적으로 모델을 갖는다. 용어를 기준으로 구분한다. 팀 조직의 규모에 따라 하위 도메인별로 각 바운디드 컨텍스트를 가질 수도 있고, ..

애그리거트의 트랜잭션 운영자와 고객이 동시에 한 주문 애그리거트를 수정하는 경우 문제점 살펴보자. 아래 두 쓰레드는 각각 트랜잭션을 커밋할 때 수정한 내용을 DB에 반영한다. [문제점] 애그리 거트의 일관성이 깨질 수 있다. (운영자가 기존 배송지 정보를 이용해서 배송상태를 변경했는데 그 사이에 고객이 배송지를 변경 할 수 있다.) [해결] 운영자가 정보를 조회하고 변경하는 동안 고객이 애그리거트를 수정하지 못하도록 막는다 운영자가 정보를 조회한 후 고객이 정보를 변경하면, 운영자가 애그리거트를 다시 조회한 뒤 수정하도록 한다. -> DBMS가 지원하는 트랜잭션과 함께 애그리거트를 위한 추가적인 트랜잭션 처리 기법(선점 잠금/비선점 잠금)이 필요하다. 애그리거트 잠금기법 선점 잠금(Pessimistic ..

응용 서비스 응용 서비스 역할 표현 영역과 도메인 영역을 연결하는 매개체 사용자가 요청한 기능을 실행한다. -> 이 처리를 위해 리포지터리에서 도메인 객체를 가져와 사용한다. 도메인 같의 객체 흐름을 담당하기 때문에 다음과 같이 단순한 형태를 갖는다. //1. 리포지터리에서 애그리거트를 구한다. //2. 애그리거트의 도메인 기능을 실행 //3. 결과를 리턴 트랜잭션 처리도 담당하여 데이터 일관성이 깨지지 않도록 한다. -> 스프링 프레임워크가 제공하는 @Transactional로 쉽게 처리 가능 "응용 서비스가 복잡하다는 생각이 든다면?" 도메인 기능을 구현하고 있는지 체크 해볼 것 다음과 같이 비밀번호 변경 기능을 담당하는 ChangePasswordService 클래스가 있다. /* 서비스에 도메인(암..

스펙(Specification) CQRS 명령(Command)모델과 조회(Query)모델을 분리하는 패턴이다. 명령모델은 상태를 변경 하는 기능을 구현할 때 사용하며 주로 도메인 모델이 이에 해된다. 조회모델은 상태를 조회 하는 기능을 구현 할 때 사용 한다. 검새조건이 단순하고 고정되어 있는경우 JPA 메소드 사용 findByEmailAddressAndLastname findAllByDescriptionContaining 검색 조건을 다양하게 조합할 때 스펙을(specification) 사용한다. /** 특정조건을 충족하는지 검사할 때 사용하는 인터페이스 */ public interface Specification { public boolean isSatisfiedby(T agg); } [주문이 특정 ..

JPA를 이용한 리포지터리 구현 레포지토리 인터페이스는 도메인 영역에, 레포지토리 구현 클래스는 인프라스트럭처 영역에 속한다. 레포지토리는 기본적으로 ID로 애그리거트 조회 하기 와 애그리거트 저장하기 두개의 기능을 제공한다. 그외에도 다음과 가능 기능을 제공할 수 있다. ID외에 다른 조건으로 조회 JPA의 Criteria나 JPQL(Java Persistence Query Language) 사용 애그리거트 삭제 애그리거트 객체를 파라미터로 받음: delete(Order order); 요구사항이 삭제이더라도, 데이터를 바로 삭제하기보다는 삭제 플래그로 처리하여 일정기간 보관하는 것도 좋음 [SpringDataJPA 구현] 스프링 데이터 JPA는 다음 규칙에 따라 작성한 인터페이스를 찾고, 그 인터페이스..

애그리거트 서비스가 커지고 도메인이 복잡해지게 되면 => 개별 구성요소 위주로 도메인을 바라보게 된다. => 전체 구조나 상위 수준에서의 관계 파악이 어려워진다. => 상위수준에서 모델이 어떻게 엮여 있는지 몰라 코드 수정을 꺼려하게 된다. => 코드변경을 회피하는 쪽으로 요구사항을 협의하게 된다. => 코드 변경이나 확장이 어려워 진다. "애그리거트" 로 위와 같은 문제를 해결 할 수 있다. 애그리거트는 관련된 객체를 하나의 군으로 묶어 준다. 많은 객체들을 애그리거트로 묶어서 바라보면 상위 수준에서 도메인 모델 관계들을 파악하기 쉽다. [애그리거트 적용 전 도메인 모델] [애그리거트 적용 후 도메인 모델] 애그리거트의 특징 복잡한 도메인을 단순한 구조로 만들어 준다. -> 모델을 보다 잘 이해할 수 ..