DDD Start- 최범균

도메인주도 설계 구현과 핵심 개념 익히기.

1. 도메인 모델 시작

도메인 모델 패턴

도메인 규칙을 객체 지향 기법으로 구현하는 패턴

• 핵심 규칙을 구현한 코드는 도메인 모델에만 위치, 규칙이 바뀌거나 규칙을 확장해야 할때 다른코드에 영향을 덜주고 변경내역을 모델에 반영
• 점진적으로 만든 도메인 모델은 요구사항 정련을 위해 도메인 전문가나 다른 개발자와 논의하는 과정에서 공유 하기도 한다.

엔티티와 벨류

• 엔티티의 가장 큰 특징은 식별자를 갖는다. (ID)
• 타입을 보고 유추가 가능하게 해서 자연스럽게 코드가 이해되도록 한다.

도메인 모델에 set 넣지 않기

밸류타입은 불변으로 구현한다.

• set 메소드는 도메인의 핵심개념이나 의도를 코드에서 사라지게 한다.
• 생성자를 통해 받을수 있도록 한다.

도메인 용어

• 도메인 용어를 사용하여 구현하는 불필요한 변환과정을 하지 않아도 된다.
• 코드로 해석하는 과정이 줄어들어 이해하는 시간을 절약한다.

도메인 영역의 주요 구성요소

• DB엔티티와 도메인모델 엔티티의 차이.
  • 도메인 모델의 엔티티는 데이터와 도메인기능을 함께 제공한다.

2. 아키텍쳐 개요

DIP

Dependency Inversion Principle

• 저수준 모듈이 고수준 모듈에 의존
• 도메인과 응용 영역에 대한 영향을 주지 않거나 최소화 하면서 구현기술을 변경
• 중간에 요구사항(저수준)이 바뀌어도 응용영역을 변경하지 않아도 된다.

애그리거트 (Aggregate)

• 도메인 모델의 구성요소는 규모가 커질수록 복잡해진다.
• 관련객체를 하나로 묶은 군집 이다.
• 전체구조를 이해하는데 도움이 된다.

리포지터리 (Repository)

도메인 객체를 영속화 하는데 필요한 기능을 추상화

• 실제 구현 클래스는 인프라 스트럭처 영역에 속한다.

인프라 스트럭처 개요 (Infrastructure)

• 표현영역/응용영역/도메인영역을 지원
• 인터페이스를 도메인영역과 응용영역에서 구현하는것이 시스템을 유연하게 만든다. ex. @Transaction - 한줄로 트랜잭션을 처리한다. > 시스템을 유연하게 만든다.

3. 애그리거트

관련한 모델을 하나로 모아 복잡한 모델을 관리하는 기준을 제공

도메인 규칙과 일관성

• set 을 안넣는 이유
  • 자연스럽게 불변 타입으로 구성하게 되어 일관성이 깨질 확률이 낮아진다.
  • 의미가 드러나는 이름을 사용하게 될 확률이 높아진다.

트랜젝션 범위

• 한 트렌젝셔에서는 한 애그리거트만 수정 해야 충돌의 가능성이 줄어든다.
• 한 애거리거트 내부에서 다른 애거리거트 상태를 변경하는 기능을 실행하면 안된다.
• 한 애거리거트가 다른 애거리거트의 기능에 의존하면 결합도가 높아지게 된다.

ID를 통한 애그리거트 참조

모델의 복잡도가 하향한다.

ID를 통한 참조와 조회 성능

• N+1 조회 문제 : 조회대상이 N개면 N번 조회 (잘못된 ORM 설계)
• join 또는 query 를 통해 해결하자.

확장

• 초기에는 단일서버에 단일 DBMS로 구성이 가능하다.
• 사용자가 늘고 트래픽이 증가한다.
• 자연스럽게 부하를 분산하기 위해 도메인별로 시스템을 분리한다.

4. 리포지터리 모델구현

JPA를통한 리포지터리 구현

• ID로 조회/애그리거트 저장
• 밸류는 @Embededable 로 매핑 설정
  • 하이버네이트는 clear() 메소드를 호출하면 delete 쿼리로 삭제를 수행
  • 수행되길 원하지 않으면 단일클래스로 구현
• 밸류타입 프로퍼티는 @Embedded 로 매핑
• 조회시점에서 완전한 상태가 되게 하려면 Fetch.EAGER (반대는 Fetch.LAZY)

영속성 전파

• 삭제메소드는 애거리거트에 속한 모든객체를 삭제 해야 한다.
• CascadeType.PERSIST, CascadeType.REMOVE

5. 리포지터리 조회 기능

• Specification 을 구현해야 한다.
• JPA 정적메타모델
  • @StaticMetamodel(~~.class)
  • Criteria 를 사용할때 StaticMetamodel을 통해 구현하는것이 코드의 안정성이나 생산성측면에서 유리하다. (오타의 위험 및 자동완성)
• Criteria 의 문제점
  • 도메인모델은 구현기술에 의존하지 않아야한다.
  • Specification 인터페이스는 toPredicate() 가 JPA 의 Root 와 CriteriaBuilder 에 의존하고 있다.

동적 인스턴스 생성

• JPQL - select 절에 new ~~Enttiy()를 넣을 수 있따.
  • ex)SELECT new OrderView(o, m, p) FROM Order o, Member m, Product p ~~
• 장점 : JPQL을 그대로 사용, 객체 기준으로 쿼리를 작성할 수 있다.
• @Imutable, @Subselect, @Syncronize : 하이버네이트 전용 애노테이션 테이블이 아닌 쿼리결과를 @Entity로 매핑 할 수 있다.
• Update가 불가하므로 @Immutable 을 선언한다.
  • 생성된 모델기준으로 생기기때문에 매핑필드변경시 불가

6. 응용서비스와 표현영역

실제 사용자가 원하는 기능을 제공하는것은 응용영역에 위치한 서비스이다.

• 도메인 로직을 넣고싶은 욕심을 참아야 한다.
• ex) if member.checkPwd() { member.changePwd() } // 도메인에서 체크하고 구현해야한다.

분산구현

장점 : 한눈에 들어와서 코드의 가독성 증가 
단점 : 코드의 응집력약화, 알아보는데 분석이 필요하다.

응용서비스의 구현

하나의 클래스에서 모두 구현할 때

관련없는 서비스, 코드가 뒤섞이는것을 조심해야 한다.
클래스의 크기(줄 수)가 커질수 있다.
분리하는게 좋음에도 억지로 끼워넣게 된다.

• 표현영역 코드
  • 애거리거트 자체를 데이터로 주고받으면 코드의 응집도를 낮추게 된다.

HttpServletRequest 나 Session 을 주고받지 말자.

• 단독 테스트가 어려워지고, 세션, 쿠키 등 표현 서비스에 있어야 하는 정보가 응용서비스로 넘어가게 되어 표현영역의 응집도가 깨지게 된다.

7. 도메인 서비스

• 여러 애거리거트가 섞이게 되면 코드의 위치 등 책임의 문제가 드러나게 된다.
• 도메인 개념이 애거리거트에 숨어들어 명시적으로 드러나지 않게 된다.

도메인 서비스를 별도로 구현한다.

• 하위 패키지를 구분하여 위치 시킨다.

8. 어그리거트 트랜잭션 관리

선점 (Pessimistic) 비선점 (Optimisitic)

• 선점
  • 사용이 끝날때가지 다른스레드가 해당 애거리거트를 수정하는것을 막는다.
  • 보통 DBMS가 제공하는 행단위 Lock 을 통해 구현한다.
  • LockModeType.PESSIMISTIC_WRITE
  • 교착상태 방지를 위해 최대 대기 시간을 설정해야 한다.
• 비선점
  • 변경한 데이터를 싲레 DBMS 에 반영하는 시점에 변경 가능 여부를 확인하는 방식
  • 구현
    • 애거리거트 버전을 함께 보내어 확인한다.

9. 도메인 모델과 BOUNDED CONTEXT

• 도메인을 완벽히 표현하는 단일 모델을 만드는 시도. 이는 실행할 수 없다.
• 구분되는 경계를 갖는 컨텍스트를 바운디드 컨텍스트 라고 부른다.

10. 이벤트

• 트렌젝션 처리가 복잡해짐에 따라 속도 및 로직이 뒤섞이는 문제가 발생한다.
• 이러한 강한 결합 (high coupling)이 생기고, 이를 해결하기 위한 방법중 하나는 이벤트를 활용하는 추상클래스를 활용하는 것이다.
• 비동기 이벤트 처리 ex)
  • 로컬 핸들러를 비동기로 실행
  • 메시지 큐를 사용 - 글로벌 트렌젝션 문제
  • 이벤트 저장소와 이벤트 포워더 사용
  • 이벤트 저장소와 이벤트 제공 API 사용

11. CQRS

Command Query Responsibility Segregation, 명령을 위한 모델과 상태를 제공하는 조회를 위한 모델을 분리하는 패턴

• 도메인 로직을 구현하는데 집중
• 구현해야 할 코드가 더 많아짐
• 더 많은 구현 기술이 필요

public static void main(String... args) {
   List<Integer> inputs = new ArrayList<Integer>(Arrays.asList(10, 30, 10, 20, 20, 10));
   int max = 100;
   for (Integer input : inputs) {
      max -= input;
   }
   if (max != 0) {
      System.out.println("invalid params");
      return;
   }
   inputs.add(0, 0);
   int rand = new Random().nextInt(100) + 1;
   int result = 0;
   int start = 0;
   int end = 0;
   for (int i = 0; i < inputs.size() - 1; i++) {
      start += inputs.get(i);
      end += inputs.get(i + 1);
      if (rand >= start && rand <= end) {
         result = i;
         break;
      }
   }
   System.out.println(rand + "::dd::" + result);
}

property.xml

<property.name>propertyresult</property.name>

<CODE>

Properties mockProperties = mock(Properties.class);
when((mockProperties.getProperty("property.name"))).thenReturn("propertyresult");

객체지향적 사고와 설계를 해야하는 이유는 사용자(관리자)의 서술적인 니즈를 비즈니스에 맞는 모델링을 하기위한 최적의 방법이기 때문이다.

1. 객체지향 사물의 분류
1. 사물(Things)은 곧 객체이다.
2. 사물에는 형태를 가진 것과 개념만 존재하는 것으로 분류할 수 있다.
3. 소프트웨어 분석 설계 구현을 한다는 것은 실세계의 사물을 가상세계의 사물로 전환 하는 것이다.
4. 객체 모델링, 데이터 모델링도 다 사물들을 관리하는 기준에 맞춰 분류하는 것이다.
5. 타입, 클래스는 객체 즉 사물을 분류했을 때 정의하는 것에 지나지 않는다.
2. 사물을 어떻게 분류할 것인가?
1. 책을 예시로 보면 책은 객체이다. 책에 대한 정보만 관리하는 것은 개념 객체이고 책의 실물을 관리하는 사물을 관리하는 객체가 구별되어 관리되어야 한다. 
2. 책이라는 객체가 책 정보에 대한 분류 기준으로 도서문헌상의 분류 규칙을 따르므로 다양한 분류체계를 관리하는 객체도 발생할 수 있다.
3. 사물은 단순이 존재한다고 하나의 객체만은 아니다.
4. 보는 관점, 각 비즈니스 도메인별로 차이가 발생하므로 사물의 분류 기준을 비즈니스 에 맞춰 모델링이 되어야 한다.

출처(http://www.slideshare.net/dahlmoon/20160131)

private Cache<String, Dto> cached = CacheBuilder.newBuilder().maximumSize(CACHE_SIZE).expireAfterAccess(
   EXPIRE_IN_MINUTE, TimeUnit.MINUTES).build();
    private Dto getDtoByCache(final String id) {
      return cached.get(id, new Callable<Dto>() {
         @Override public Dto call() throws Exception {
            return target.getDtoById(id);
         }
      });
   }

1. OOP

Class를 통한 설계만이 가능하여 OOP가 강제된다.

기존 설계에 대한 지식이 없는 사람은 코딩에 난항을 겪는다.

2. 기본 API

MSDN, 파이썬과 비교하면 기본 API가 (많이) 부실하다. 

3. Primitive Type

컴파일러의 고도화가 이루어지지 않았다. 성능 때문에 타협한 원시타입이 API를 너무 복잡하게 만든다. 

int , Integer, long, Long 등 ..

4. import API진입 장벽

여러곳에서 주입하여 사용하는 API의 기술이 후지다. 적용하는데 많은 노력이 필요하다. 

5. 프레임워크

다각도에서 만들어진 프레임워크들은 자바를 자바가 아닌 방식으로 사용하게 만든다.

설계나 아키텍쳐를 획일화 하거나, 간접적이거나, 사용하는 진입장벽을 만든다. 

6. 버전 마다 다른 개발방식 요구

java 6과 7의 프로그래밍 방식은 완전히 다르다. 8또한 완전히 또 다르다.

VisualVM 은 자바 어플리케이션의 상태를 보여주는 내장 기본 기능이다.

visual 이라는 말에서도 볼수 있듯 자바 명령어로도 노출 되는 모든 정보는 조회 가능하다.

MBean 관련 라이브러리의 커맨드를 사용하면 된다.

ex) http://stackoverflow.com/questions/26130824/getting-java-visualvm-data-from-the-command-line

ObjectName jvmMemory = new ObjectName("java.lang", "type", "Memory");           
CompositeData heapUsage = (CompositeData) mbsc.getAttribute(jvmMemory, "HeapMemoryUsage");
printer.print(String.valueOf(heapUsage.get("used")));
printer.print(String.valueOf(heapUsage.get("committed")));
printer.print(String.valueOf(heapUsage.get("max")));

https://visualvm.java.net/ko_KR/gettingstarted.html

객체지향 프로그래밍이란

상속관계로 클래스 계층구조를 형성하고,

클래스에 대한 인스턴스(필드)는 객체로 표현하며,

객체가 모여 서로 협조(사용)하며

조직을 이루게하는 구현방식이다.

Collections.sort(list, new Comparator<SomeDto>() {
   @Override
   public int compare(SomdDto o1, SomeDto o2) {
      return o1.getCreatedAt().compareTo(o2.getCreatedAt());
   }
});

객체안 값을 비교하여 sort Collections sort