[Layer Architecture] 레이어 아키텍처

애플리케이션 아키텍처와 객체지향 - 조영호

유튜브 링크

슬라이드 링크

조영호님의 애플리케이션 아키텍처와 객체지향 영상을 정리한 블로그 입니다. 사용한 이미지는 대부분 위 슬라이드 링크에서 캡처한 것입니다.

관심사의 분리(Separation Of Concerns)

아이텍처를 결정할 때 관심사의 이야기를 많이 합니다. 관심사란 유사한 책임을 의미합니다.

레이어 아키텍처

유사한 관심사들을 레이어로 나눠서 수직적으로 배열하는 아키텍처입니다.

레이어 아키텍처는 케익과 같습니다. 유사한 관심사들이 층별로 나눠줘 있고 필요한 경우 한 층을 다른 것으로 교체해도 그 구조가 유지됩니다. 유사한 역활을 한 레이어에 모아 놨으니깐 그 레이어만 교체하면 전체 시스템을 다른 환경에서도 사용할 수 있어야 합니다. 즉 유연성과 재사용성이 높다는 장점을 가지고 있습니다.

아키텍처는 보통 3종류로 나뉩니다.

Presentation

화면 조작 또는 사용자의 입력을 처리하기 위한 관심사를 모아놓은 레이어

Domain

비즈니스와 관련된 도메인 로직을 처리하는 레이어

Data Source

도메인에서 필요로 하는 모든 데이터를 조작하기 위한 레이어

비즈니스 로직이 들어가 있는 도메인 레이어가 가장 중요합니다. 우리는 도메인 레이어를 통해 전체 아키텍처 구성을 결정합니다.

도메인을 짜는 2가지 방법

1. 절차지향(Transaction Script)

2. 객체지향(Domain Model)

위 개념을 온라인 영화 예매 시스템을 통해 살펴보겠습니다.

도메인 컨셉

우리가 예매하는건 영화(Movie)가 아닌 그 영화가 언제 상영하는지를(Showing) 예매하는 것입니다. 그리고 영화 예매 시스템에는 할인(Discount) 정책이 있습니다.

할인 정책(조건을 만족 할 때 얼만큼의 금액을 빼줄지를 결정)

1. 특정한 금액을 빼주는 것 Amount Discount

2. 비율을 주는 것 Percent Discount

할인 규칙(언제, 어떤 조건에 만족할 때 예매 금액을 할인 해줄 것인가를 결정)

1. 그날의 몇 회 상영일 때 할인 Sequence Rule

2. 특정 시간에 상영일 때 할인 Time Rule

트랜잭션 스크립트

데이터와 프로세스가 따로 존재 한다.

1. 데이터베이스로 부터 Movie, Showing, Rule 조회

2. Showing에 적용할 수 있는 Rule이 존재하는지 판단

3. if(Rule이 존재하면) { Discount를 읽어 요금 할인된 요금 계산 } else { Movie의 정가를 이용해 요금 계산 }

4. Reservation 생성 후 데이터베이스 저장

도메인 모델

객체지향 기반의 도메인 레이어를 설계한다. 

1. 프로세스와 데이터를 하나의 덩어리로 생각하는 것

2. 주어진 책임을 수행하는 객체들의 협력을 통해서 이뤄짐

CRC Card

영화 예매를 하는데 어떤 역활이 필요해? 어떤 객체가 필요해? 그러면 그 객체가 어떤 책임을 가져야해? 그러면 그 책임을 수행하는데 어떤 협력자가 필요해?

예매 생성 책임 할당

누가 예매를 생성하는게 적절할까?

객체라는 것은 상태와 행동을 같이 가지는 것이다. 어떤 상태가 있을 때 그 상태를 변경하고 조작하는 행동은 같이 있어야 한다. 상태와 행동을 같이 두어야 캡슐화를 지킬 수 있다.

책임할당의 원칙

책임을 수행하는데 필요한 데이터를 가지고 있는 객체에 책임을 할당한다. 책임 할당 패턴 중 Creator 패턴이라고 부른다. 어떤 객체를 생성하는 책임은 그 객체를 생성하는데 필요한 데이터(정보)를 가장 많이 알고 있는 객체에 할당해야 한다.

- 예매 생성은 Showing 에 할당

- 가격 계산은 Movie에 할당

- 할인률 계산은 Discount Strategy에 할당

- 할인 여부 판단은 Rule에 할당

도메인 레이어와 아키텍처

도메인 레이어를 어떻게 짜느냐에 따라 전체 아키텍처의 구조가 달라진다.

서비스 레이어

도메인과 프레젠테이션 로직 사이에 존재한다.

어플리케이션 로직을 순수한 객체에 넣지 않는다. 그러면 디팬던시가 생기고 테스트 하기 어렵고 결합도가 높아지며 응집도가 떨어진다. 도메인 레이어를 캡슐화하기 위해 서비스 레이어를 만들어 준다.

객체-관계 임피던스 불일치

도메인 레이어를 사용할 때 객체 모델와 DB 스키마 사이의 불일치가 발생한다.

데이터 매퍼

매퍼를 중간에 둬서 도메인 쪽에 있는 객체와 DB 간의 결합도를 끊어 준다. 즉 도메인 객체는 DB에 대해 독립적이어야 한다. 여기서 데이터 매퍼는 흔히 ORM(Object Relational Model)이라고 한다.

어떻게 쓸 것인가?

예를 통해 확인해 보자. 만약 중복할인이라는 개념을 추가하게 되면 어떨까

트랜지션 스크립트를 사용할 경우

트랜지션 스크립트에서는 What이 아닌 How를 봐야 도메인 개념을 유추할 수 있다. 또한 기존 코드를 건드려야 되며 중복 할인 이라는 개념을 명시적으로 보여줄 수 없다. 하지만 절차적으로 개발할 경우 단순하거나 변경이 적은 케이스에는 적합하다. 또한 알고리즘 위주에 설계에서는 절차적 개발이 더 적합 할 수 있다.

도메인 모델을 사용할 때

컴포지트 디자인 패턴을 사용한다. Movie의 입장에서는 하나의 DiscountStrategy나 여러개의 DiscountStrategy나 동일하다. 기존의 Strategy를 상속해서 새로운 DiscountStrategy를 추가한다.

즉 기존 코드를 수정하지 않고 새로운 기능을 추가할 수 있다. 수정에는 닫혀 있지만 행동을 확장하고 변경하는게는 열려있게 되므로 OCP 원칙을 준수하게 된다. 또한 의존성의 방향이 추상화 쪽으로만 이뤄지는데 상위 레벨의 모듈은 하위 레벨의 모듈에 대한 디팬던시가 전혀 없으므로 DIP 원칙을 지키고 있다.