일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- spring boot
- Stream
- Design Pattern
- 자바8
- Java8
- jsp
- Template Method Pattern
- 디자인 패턴
- Java 8 in action
- 자바
- head first
- Java8 in action
- spring
- Java in action
- Was
- ddd
- AWS101
- facade pattern
- 클린코드
- web
- Clean Code
- 자바8인액션
- 스트림
- CQRS
- spring Batch
- SERVLET
- 패스트캠퍼스
- 자바의 신
- Java
- domain
- Today
- Total
목록개발 성장기 (34)
주난v 개발 성장기
애그리거트와 트랜잭션 운영자 스레드와 고객 스레드는 개념적으로 동일한 애그리거트지만, 물리적으로는 다른 애그릭더트 객체 이다. 운영자 스레드가 주문 애그리거트 객체의 배송 상태를 변경했는데, 고객이 그 사이에 배송지 정보를 변경 --> 애그리거트의 일관성이 깨진다. 이를 보완하는 트랜잭션 처리 기법이 필요! 1. 선점(Pessimistic) 잠금 - 먼저 애그리거트를 구한 스레드가 사용이 끝날 때까지 다른 스레드가 해당 애그리거트를 수정하는 것을 막는다. 한 스레드가 애그리거트를 구하고 수정하는 동안 다른 스레드가 수정할 수 없으므로, 동시에 데이터를 수정하는 충돌 문제 해결 가능 선점 잠금 방식은 DBMS가 제공하는 행 단위 잠금을 사용해서 구현한다. LockModeType.PESIMISTIC_WRIT..
여러 애그리거트가 필요한 기능 한 애그리거트로 기능을 구현할 수 없을 때가 있다. (ex. 결제 금액 계산 로직...상품 / 주문 / 할인 쿠폰 / 회원 애그리거트를 모두 필요로 함) 주문 금액을 계싼하는 것은 주문 애그리거트에서 할 수 있지만, 실제 결제 금액은 누구의 책임일까..? 주문 애그리거트가 필요 데이터를 모두 가지고, 주문 애그리거트에서 처리..? 계산 로직이 주문 애그리거트에 있는 문제 할인 건이 생겨도, 주문 쪽 코드를 수정해야 함 --> 애그리거트는 자신의 책임 범위를 넘어서는 기능을 구현, 의존성이 증가 도메인 서비스 한 애그리거트에 억지로 넣기보다 도메인 서비스를 이용해서 도메인 개념을 명시적으로 드러내면 된다. public class DiscountCalculationService..
코드의 중복, 직접적인 의존 해결에 도움을 주는 패턴 하위 시스템을 쉽게 사용하게 해주는 인터페이스 정의 고수준의 인터페이스를 정의하기 때문에, 서브 시스템을 쉽게 사용할 수 있다.(캡슐화) 사용처 - 캡슐화 되지 않은 코드 처리시에 사용 - 원하는 코드를 다시 작성할 수 없을 때 사용 예시 집에서 영화를 보기 위한 홈 씨어터 시스템을 구축한다고 가정. - DVDPlayer, Cdplayer, Projector, Screen, 등 다양한 클래스들이 필요하다. 영화를 보기 위한 일련의 행동을 나열한다면.. 1. 팝콘 기계를 켜고 2. 튀기고 3. 전등을 어둡게 하고 4. 스크린을 내리고....이를 코드로 나열하자면..Too much....(특히 클라이언트 입장에서) 퍼사드 패턴을 이용하여, 코드를 보면
도메인 영역만 잘 만든다고, 사용자의 요구를 충족한다고 끝나는 것은 아니다. 도메인이 제 기능을 하려면 사용자와 도메인을 연결해 주는 매개체가 필요하다. (표현 - 응용 - 도메인) 표현 영역 - 사용자의 요청 해석 (어떤 기능을 실행하고 싶어하는지...), 응용 서비스 실행 - 응용 서비스에서 원하는 형태로 사용자의 요청을 변환 응용 영역 - 기능 제공 - repository로 부터 도메인 객체를 구하고, 사용 - 유효성 검사, 애그리거트 CRUD, 결과 리턴 이외의 것이 들어있으면 도메인 로직의 일부를 구현하고 있을 가능성이 있다. - 트랜잭션 처리 도메인 로직 넣지 않기 public class ChangePasswordService { public void changePassword(String m..
repository는 애그리거트의 저장소 find 메서드 정의로 조회를 할 수 있지만, 너무 많아지고 조합이 다양할 경우 스펙(Specification)을 이용 스펙(specification)은 애그리거트가 특정 조건을 충족하는지 여부를 검사 public interface Speficiation { public boolean isSatisfiedBy(T aggregation); } public class OrdererSpec implements Specification { private String orderId; public OrdererSpec(String ordererId) { this.ordererId = ordererId; } @Override public boolean isSatisfiedBy..
JPA를 이용한 리포지터리 구현 - 애그리거트를 어떤 저장소에 저장하느냐! - RDBMS를 사용한다면 JPA를 들 수 있다. - 도메인 모델과 관계형 데이터 모델 간의 매핑 처리 기술(ORM - Object Relation Mapping) 모듈 위치 팀 표준에 따라 domain.impl에 인프라 스트럭쳐 코드를 구현할 수 있지만, 좋은 설계는 아니다. 가능하면 구현 클래스를 인프라 스트럭쳐에 위치시켜 의존을 낮춰야한다. 매핑 구현 애그리거트 루트는 엔티티 이므로, @Entity로 설정한다. @Embeddable public class Orderer { @Embedded @AttributesOverrides( @AttributeOverride(name = "id", column = @Column(name ..
애그리거트는 관련된 객체를 하나의 군으로 묶어준다. 애그리거트를 이용하여 모델 간의 관계를 개별 수준뿐만 아니라 상위 수준에서도 이해가능하다. 일관성을 관리하는 기준이 되기도 한다. 애그리거트 관련된 모델을 하나로 모은 것 동일한 라이프 사이클 Order가 생성되면, OrderLine, ShippingInfo등 애그리거트에 속한 구성 요소는 대부분 함께 생성하고 소멸된다. 애그리거트는 경계를 가진다. 경계의 설정은 도메인 규칙, 요구사항이 중요하다. 하지만, 'A가 B를 갖는다'고 가정한다면 A와 B를 한 애그리거트로 묶어서 생각하기 쉽다. 그러나 그렇지 않다. Product - Review같은 경우는 함께 생성되거나 변경되지 않고, 변경주체도 다르다. 애그리거트 루트 구매할 상품의 개수를 변경하면, O..
네 개의 영역 표현 영역 사용자의 요청을 받아 응용 영역에 전달 응용 영역의 처리 결과를 다시 사용자에게 전달 도메인 영역 도메인 모델 구현 Order, OrderLine 등이 도메인 모델 영역에 위치한다. Entity, Value Object 인프라스트럭처 영역 구현 기술 RDB, SMTP, Queue 계층 구조 아키텍쳐 도메인의 복잡도에 따라 응용과 도메인을 분리하기도 하고, 합치기도 한다. 계층 구조는 상위 계층에서 하위 계층으로만 의존하고, 역으로는 발생하지 않는다. 응용 영역과 도메인 영역은 DB나 외부 시스템 연동을 위해 의존하나, 응용에서 도메인을 무조건 의존 할 필요는 없다. 결국, 표현 - 응용 - 도메인 계층은 모두 인프라스트럭처에 의존하게 되고, 별도의 외부 기술(가격 할인 등)과 같..