[재준]_3장-4장.md

3장. 모델 주도 설계

좋은 모델을 만든 후 발생할 수 있는 문제점

모델을 만드는 과정도 중요하지만 결국에는 모델을 가지고 코드로 구현하는 작업을 거친다.

여기서 모델을 적절하게 코드로 구현하지 못한다면 신뢰할 수 없는 소프트웨어를 만들게된다.

따라서 우리는 근본적으로 모델을 코드로 어떻게 변환할 것인가? 생각을 항상 가지고 있어야한다.

왜? 개발자들은 좋은 모델을 가지고 구현을 잘하지 못할까?

개발자들은 모델을 원천으로 아이디어를 얻고 거기에 자신이 생각하는 아이디어를 추가한다.

이러한 과정이 나쁘다고 말할 수 없지만 시간이 지날수록 점점 원본 모델과는 간극이 발생하게된다.

내가 생각한 예시는 다음과 같다.

다음과 같이 첫 설계는 주문과 메뉴의 관계만 나타내도 분석가 입장에서는 문제가 없을 것 같다.

하지만 개발자 입장에서 보면 해당 연관관계는 N:M 관계임으로 해당 관계를 풀어내고자 할 것이다.

따라서 다음과 같이 기존 설계와 다르게 다음과 같이 풀어낼 것이다.

지금 당장에는 모델 변화가 그렇게 크지는 않지만 위에서 말하는 것처럼

시간이 지날수록 이러한 과정이 많아진다면 점점 원본 모델과 간극이 발생할 것이다.

그럼 어떻게 해야할까?

• 분석 모델과 코드설계를 분리한다.
• 개발자들을 피드백 제공자로 동참시켜라.
• 도메인 모델링과 설계를 밀접하게 관련시켜라.
• 설계에 사용할 용어와 각 설계 요소가 기본적으로 수행해야 할 책임들은 모델로부터 도출하도록 한다.
• 모델링 패러다임을 지원하는 개발 툴이나 언어를 사용하라(객체지향 프로그래밍)

모델 주도 설계에서 사용되는 중요 패턴

계층형 아키텍쳐

• 애플리케이션에서 상당부분은 도메인과 직접적인 관련이 없다.
  • 대부분 데이터베이스 접근, 사용자인터페이스 등 도메인과 직접 관련되지 않은 지원 성격의 코드들이 존재한다.
  • 이러한 코드들 즉 도메인과 관련되지 않은 코드들을 애플리케이션 로직이라고 부른다고합니다.(아래 참고영상 두번째 48분부터 보시면 됩니다.)
  • 만약 애플리케이션 로직과 도메인 로직이 같이 있다면 UI 관련 로직이 도메인 로직까지 영향을 끼칠수 있다.
  • 이러한 현상을 피하기위해 Layer 로 분리하여 높은 응집도와 낮은 결합도를 가지기위해 계층형 아키텍처 패턴을 사용한다.
• 계층형 아키텍쳐는 4개의 개념적 레이어를 포함한다.
  • 사용자 인터페이스
  • 애플리케이션 레이어
  • 도메인 레이어
  • 인프라 스트럭처 레이어

엔티티(Entity)

• 엔티티의 개념의 핵심은 식별자를 가지고있는 객체이다.
• 즉 이 식별자가 같다면 내부 값이 같지않더라도 같은객체로 본다는 것이다.(위 예시는 RRN 이 식별자 입니다.)
• 따라서 이 식별자는 유일성을 보장해야한다.
• 또한 식별자를 가진다는 것은 항상 추적가능해야 하며 이에 따른 비용이 든다.

값 객체(Value Object)

• 유사한 속성을 가지고있는 값들을 모아 객체로 만든것을 값 객체라고 부른다.
• 값으로만 존재하면 어떠한 기능을 제공하기 힘들지만 값 객체로 만들면 기능을 추가(메소드를 가질 수 있음) 할 수 있다는 장점이있다.
• 값 객체의 기준을 판단하기 좋은방법으로 어떠한 값에 prefix, suffix 가 동일하다면 높은확률로 값 객체로 만들어야 한다는 신호이다.
  (EX: 예약시작시간(value), 예약끝나는시간(value) -> 예약시간(object))

궁금한 점🤔: 책에서 소개하는 내용으로는 값 객체를 생성하고 나서는 생명주기 동안 상태를 변경시키면 안된다고 하는데 여기서 Setter 메서드나 update 메서드 둘다 제공하면 안된다는 건가요? 만약 맞다면 값을 변경하기위해서는 VO 객체를 항상 다시 만들어서 변경하라는 이야기인가요?

서비스(Service) - 이 부분은 조금 어렵네여..

• 이 책에서 말하고자하는 서비스는 정확히 도메인 서비스 를 말하고싶은것 같다.
• 도메인의 명사(value)와 연관되어서 행위(method)를 나타내는 것은 도메인 서비스에 정의가 되어야한다.
• 도메인 서비스의 세가지 특징은
  • 서비스에 의해 수행되는 오퍼레이션은 일반적으로 엔티티 또는 값 객체에 속할 수 없는 도메인의 개념을 나타낸다.
  • 수행되는 오퍼레이션은 도메인의 다른 객체를 참조한다.
  • 오퍼레이션은 상태를 저장하지 않는다.

모듈

• 관련된 개념과 작업을 조직화하여 복잡도를 감소시키는 기법이다.
• 모듈을 사용하게 된다면 코드가 높은 응집도와 낮은 결합도를 추구할 수 있다.
• 응집도와 결합도는 변경에 초점을 맞추어 보면 쉽다.
  • 특정 기능을 변경할때 여러군데를 변경해야하는가? -> 응집도가 낮음
  • 변경이 일어날때 다른 클래스에 영향이 가는가? -> 결합도가 높음

집합(Aggregate)

• 간단히 말하자면 객체간 연관관계에 있어 과도한 객체그래프 탐색을 하지말라고 말하고 싶은것 같다.

• 복잡한 연관관계는 소프트웨어 유지보수를 힘들게하며 성장속도를 더디게 만든다.

• 따라서 연관관계는 단방향으로 유지하며 어떠한 객체의 특정 기능이 필요한경우 Root 객체로부터 접근하여 참조하라.

• 아래의 참고영상에 우아한 객체지향을 보시면 도움이 많이 될 것 같습니다.

팩토리(Factory), 리포지토리(Repository)

• 리포지토리는 Aggregate 의 Root 에 해당하는 모델 말고는 만들지 말라는 이야기인가요?
  (그렇다면 JPA 영속성 전이를 이용하라는건가요..? ㅋㅋ 어렵쓰)

• 이 두 부분은 아무리 읽어도 너무 추상적이여서 정리를 하지 못하겠습니다 😥(예제도 마음에 와닿지 않고 ..)

• PASS !

4장. 깊은 통찰을 통한 리펙터링

지속적인 리팩터링

• 리팩터링이란?

  • 리팩터링이란 애플리케이션의 기능에 변화를 주지않고 코드를 더좋게 만들기 위해 제설계하는 절차다.

  • 리팩터링은 대체로 작은규모로, 제어가능한 절차를 적용하면서 기존에 정상적으로 동작하던 기능을 손상시키거나 버그를 추가해서는 안된다.

  • 따라서 리펙터링을 진행할때에는 반드시 자동화테스트를 만들어 리팩터링 과정에서 기존 기능을 망치지 않았음을 보장해야한다.

• 핵심개념 드러내기

  • 앞서 소개한 리팩터링은 패턴을 기반한 리팩터링이다.
  • 코드를 더 좋게 만드는 리팩터링도 중요하지만 모델의 핵심개념을 드러내는 개선도 중요하다.
  • 즉 모델 초기에는 당연히 모델에 대한 깊은 이해를 할 수 없다. 하지만 프로젝트를 진행함에 있어 깊은 통찰을 가지도록 개선해야한다.
  • 도메인의 암시적 개념 -> 명시적 개념으로 변환(제약조건, 처리, 명세를 이용하여)

이해하는데 도움이 되었던 영상

• 우아한 객체지향
• Growing Application - 2nd. 애플리케이션 아키텍처와 객체지향
• DDD Start 수다

좋은 내용이 많으니 주무실때 10분씩 보시면 좋을것 같아요!