일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- domain
- Java in action
- 클린코드
- Design Pattern
- Stream
- facade pattern
- 패스트캠퍼스
- spring
- Java
- jsp
- head first
- Template Method Pattern
- Clean Code
- web
- 자바8
- Java8
- Was
- 스트림
- SERVLET
- 자바8인액션
- 디자인 패턴
- Java8 in action
- Java 8 in action
- spring Batch
- ddd
- CQRS
- AWS101
- 자바의 신
- spring boot
- 자바
- Today
- Total
목록Java (21)
주난v 개발 성장기
자바 8에서 변화가 많이 일어났다. 사과 리스트 정렬 코드 //JAVA8 이전 Collections.sort(inventory, new Comparator() { public int compare(Apple apple1, Apple apple2) { return apple1.getWeight().compareTo(apple2.getWeight()); } } //JAVA8 inventory.sort(comparing(Apple::getWeight()); 멀티코어 CPU 대중화와 같은 하드웨어적인 변화도 자바 8에 영향을 미쳤다. 대부분 쿼드 코어 이상의 CPU를 사용할 것이다. 자바8이 등장하기 이전에는 나머지 코어를 활용하려면 스레드를 사용하는 것이 좋다고 조언했지만, 관리하기 어렵고 문제가 발생 자바 ..
CQRS - Command Query Responsibility Segregation 단일 모델의 단점 조회 화면의 특성상 속도가 빨라야 하는데, 여러 애그리거트에서 데이터를 가져와야 할 경우 구현 방법을 고민해야 한다. (ex. 주문 상세 조회 시에 주문, 상품, 회원 정보를 모두 조회해한다.) ID를 이용해서, 애그리거트를 참조하는 방식을 사용하면 즉시 로딩과 같은 최적화 기능을 이용 못하고, 여러번 select를 해야함으로 속도에 문제가 생긴다. ID가 아니라 직접 참조하는 방식으로 연결해도 즉시 로딩이나 지연 로딩을 처리해야 하므로, 네이티브 쿼리를 사용해야 할 수도 있다. 이러한 고민은 단일 도메인을 사용하기 때문이다. 해결법은 상태 변경을 위한 모델과 조회를 위한 모델을 분리하는 것! CQRS..
org.springframework.dao.DuplicateKeyException: PreparedStatementCallback; SQL [INSERT into BATCH_JOB_EXECUTION(JOB_EXECUTION_ID, JOB_INSTANCE_ID, START_TIME, END_TIME, STATUS, EXIT_CODE, EXIT_MESSAGE, VERSION, CREATE_TIME, LAST_UPDATED, JOB_CONFIGURATION_LOCATION) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)]; (conn=21562) Duplicate entry '0' for key 'PRIMARY'; nested exception is java.sql.SQLIntegr..

애그리거트와 트랜잭션 운영자 스레드와 고객 스레드는 개념적으로 동일한 애그리거트지만, 물리적으로는 다른 애그릭더트 객체 이다. 운영자 스레드가 주문 애그리거트 객체의 배송 상태를 변경했는데, 고객이 그 사이에 배송지 정보를 변경 --> 애그리거트의 일관성이 깨진다. 이를 보완하는 트랜잭션 처리 기법이 필요! 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..

애그리거트는 관련된 객체를 하나의 군으로 묶어준다. 애그리거트를 이용하여 모델 간의 관계를 개별 수준뿐만 아니라 상위 수준에서도 이해가능하다. 일관성을 관리하는 기준이 되기도 한다. 애그리거트 관련된 모델을 하나로 모은 것 동일한 라이프 사이클 Order가 생성되면, OrderLine, ShippingInfo등 애그리거트에 속한 구성 요소는 대부분 함께 생성하고 소멸된다. 애그리거트는 경계를 가진다. 경계의 설정은 도메인 규칙, 요구사항이 중요하다. 하지만, 'A가 B를 갖는다'고 가정한다면 A와 B를 한 애그리거트로 묶어서 생각하기 쉽다. 그러나 그렇지 않다. Product - Review같은 경우는 함께 생성되거나 변경되지 않고, 변경주체도 다르다. 애그리거트 루트 구매할 상품의 개수를 변경하면, O..