잡소리2

https://www.youtube.com/watch?v=26S4VFUWlJM

 

마틴 파울러가 이렇게.

Transaction Script (절차지향)

Domain Model (객체지향)

* Table Module 패턴 (테이블 = Entity 완전 동일하게 사용)은 자바쪽에선 거의 사용안함.

 

💭 도메인 레이어가 전체 아키텍처를 구성한다.

도메인을 어떻게 짜느냐에 따라 아키텍처 구성이 달라진다.

💭 요구사항 살펴보기

온라인 영화 예매 시스템을 Transcation Script와 Domain Model로 나누어서 구현해보자.

비즈니스 기능 : 영화를 예매한다.

도메인 개념 : 시스템을 구현하는 개념들

[영화] - 메타데이터. 영화에 대한 정보

[상영] - 예매할 주체

[할인] - 소비자를 특정한 시간대로 유도하기 위한 할인

할인 정책 : 고정금액 할인, 비율 할인

할인 규칙 : 특정시간 할인, 특정 정책 할인(아침영화, 10회 상영)

요구사항을 바탕으로 3개의 도메인이 만들어졌다. 영화, 할인, 규칙

실제 시나리오를 살펴보자. 무슨 도메인이 더 필요할까?

 

요구사항에 따라 분석해보면, 아래와 같은 최종 도메인(또는 후보 도메인)이 만들어진다.

 

 

💭 1. 트랜잭션 스크립트로 만들어보기 (절차지향)

Process와 Data가 따로 논다.

[데이터] 무엇을 저장해야 하는가?

필요한 데이터 모델을 전부 설계한다.

데이터 모델을 그대로 배치한 [도메인 클래스]를 배치한다 - Anemic Domain Model (빈약한 도메인 모델)

그래도 나름 객체지향적으로 Private 속성, Getter Setter는 구현

객체지향적으로 도메인을 사용하기 위한 DAO(Data Access Object)를 구성한다.

이를 테이블 데이터 게이트웨이라고도 부른다.

이제 [프로세스]를 고민한다. 이 데이터를 어떻게 처리할까?

이제 만들어진 DAO를 바탕으로 비즈니스 로직을 만든다.

public Reservation reserveShowing(int customerId, int showingId, int audienceCount){

    🚩1 //데이터베이스로 부터 Moving, Showing, Rule 조회
    🚩2 //Showing에 작성할 수 있는 Rule이 존재하는지 판단
    
    🚩3 if(Rule이 있다면){
    	//Discount를 읽어 할인된 요금을 계산
    } else {
    	//할인 없이 Moive의 정가를 이용해 요금 계산
    }
  
    🚩4 //Reservation 생성 후 데이터베이스 저장
    return result;
}

전형적인 트랜잭션 스크립트의 구현방법.

모든 서비스가 스크립트(서비스)에 집중되어 있다.

물론 도메인이 간단하다면 절차적으로 만드는게 훨씬 나을 수 있다.

 

💭 2. 도메인 모델로 구현하기 (객체지향)

객체지향이란. 주어진 책임을 수행하는 객체들의 협력.

혼자서 문제를 해결할 수 없다. 객체간의 메시지를 보내서 문제를 해결한다.

 

객체들이 어떻게 상호작용하는지 파악한다. CRC 카드

역할을 맡을 후보(Showing)와 책임(~한다)을 정하고, 협력할 객체(Moive)를 정한다.

객체가 행동과 상태를 함께 다뤄야한다. (데이터를 가지고 있는 객체가 그 데이터를 다루어야 한다.)

만들어진 도메인을 바탕으로 책임을 담당할 객체를 설계한다. 이는 요구사항에서 부터 정의된다.

Showing. 예매 생성의 책임 할당

Movie. 영화 가격 계산 책임 할당

Discount Strategy. 할인 가격을 담당하는 책임을 할당

Rule. 할인 여부를 담당하는 객체를 할당

 

이제 객체를 설계한다. 자신의 책임이 아닌 일은, 다른 객체에게 메시지를 보내 동작을 위임한다.

처음부터 객체를 완성하는게 아니다. 각 요구사항마다 필요한 메서드를 만들어나간다.

[영화 예매]라는 서비스를 만들려면, 4가지 객체가 협력해야한다. 

할인 전략

할인 여부

객체들의 협력관계를 그려보면 아래와 같이 나오게 된다.

문제를 객체들의 협력으로 해결한다.

이를 책임 위임(delegated) 또는 분산(dispersed) 제어 스타일이라고도 부른다.

 

가장 큰 차이는 어플리케이션 로직을 객체안에 넣지 않는다.

객체는 자신이 맡은 책임만 담당할 뿐, 본인이 어디에서 호출되는지에 어플리케이션에 대한 정보를 가지고 있지 않다.

네트워크나 DB 같은 곳에 종속성이 생기면서 테스트도 어렵고, 객체간 결합도가 높아지고, 데이터 응집도가 떨어지기 때문이다.

 

즉, 흔히 4단계 아키텍처 [표현-서비스-도메인-인프라]에서 어플리케이션 부분은 서비스에 넘긴다.

서비스 레이어는 도메인을 이용해서 어플리케이션을 구성한다. 트랜잭션 또한 서비스 레이어 단위로 걸린다.

도메인은 어떠한 종속성도 가지지 않는다. 재사용이 가능하다.

필요한 것을 인프라로 읽어서 도메인 객체에 위임하는 역할. Service

어플리케이션 관심사 -> 서비스

도메인 관심사 -> 도메인

수정할 때 어디를 건드려야할까? 변경이 전체에 영향이 간다.

 

그러나 이렇게 만들면 DB를 짜기 어렵다.

왜? 객체 모델과 DB 스키마는 불일치 하기 때문에.

어플리케이션은 유연성과 유지보수가 중요하지만

DB는 데이터의 중복, 성능이 중요하다. 유연성이 중요하지 않다.

그래서 Mapper를 써서 결합도를 끊는 것이다. (임피던스 불일치 해결)

양쪽이 각자의 역할을 충실히 맡을 수 있도록. 따로 따로 놀 수 있도록

Domain 모델은 Service가 있어야 한다. [도메인 객체]들은 어플리케이션 동작, 트랜잭션에 대해서 모르기 때문이다.

 

무엇을 사용할 것인가?

변하지 않는 것은, 모든 것이 변한다는 사실 뿐이다.

소프트웨어는 설계도가 완성된 건축물이 아니다.

고객과 계속해서 소통하면서 끊임없이 변화하고 개선된다.

도메인 컨셉 또한 바뀔 수 있다.

처음 만들땐 트랜잭션 스크립트가 DB를 만들기도 편하고, 간단할 수 있다.

하지만 이는 변화를 감당하기엔 너무 벅차다. 여러 책임이 한 곳에 뭉쳐있고, 외부 네트워크, DB와도 강력하게 연결되어있기에 테스트하기도 어렵다. 결합도가 너무 높다.

또 응집도가 낮아서, 내가 수정할 부분을 찾기 어렵다. 여기저기 다 뒤져야한다.

 

➡ 클래스를 추가하고, 기능을 수정했을 때 두려움이 생긴다. 테스트가 불가능하고, 변경이 여기저기 전파되기 때문

또한 메서드가 너무 커서 테스트 하는 것 자체도 너무 어렵다. 비즈니스 요구사항이 숨어있다. (암묵적이다)

코드 상에서 중복할인이라는 개념을 찾을 수 있을까?

변경하기 어려운 것, 중요한 것

일찍, 올바르게 결정하고 싶은 것

객체지향은 추상화를 통해 효율적인 커뮤니케이션 할 수 있다.

영화(Movie)는 할인 정책(DiscountStrategy)에 따라 가격을 할인(Rule) 받을 수 있어

 

이렇게 도메인을 추상화해서 뽑고, 뽑은게 결국 Domain Layer Architecture

 

도메인 모델은 복잡성을 알고리즘에서 분리하고, 객체 간의 관계로 만든 것

유효성 검사, 계산등 포함된 복잡하고  끊임없이 변하는 비즈니스 규칙을 구현해야한다면 좋은 방법

 

💭 요구사항이 어떻게 변경될지 알 수 있나요?

몰라요. Movie를 제외하곤 전부 바뀔 수 있어요.

그래서 최대한 '단순하고 깔끔하게' 만들어야 합니다. 계속해서 리팩토링 해야합니다.