도메인 로직에 따른 프로젝트 설계
- 주먹구구 식으로 하던 프로젝트 구성이 아닌 프로젝트 구성의 필요성
- 도메인, 객체 지향, 연관 관계, ERD, 클래스 다이어그램 등 전반적인 공부를 위함
KSUG 발표 - 소프트웨어 아키텍처와 객체지향
게시글 테이블을 어떻게 만들까?
- 도메인 내 엔티티 추출
- 엔티티 간 연관 관계 정의
- 연관 관계 정의 시 DB 스키마 나옴
- 유저라는 엔티티와 게시글이란 엔티티를 정의
- 유저와 게시글의 관계는 1:N 의 관계로 이어질 수 있겠고, 게시글은 유저가 만드는 컨텐츠이므로 유저에 종속성을 소유
이런 방식으로 엔티티를 정의하고 연관관계를 서술, 이걸 DB 엔진에서 지원하는 방식으로 연결하는 것을 도메인 로직에 따른 연관관계 설정과 테이블 설계라고 함.
절차 지향과 객체 지향
- 객체 지향 언어로 구현 하지만 절차 지향적 모델링을 가지면 트랜잭션 스크립트
객체 지향적 모델링, 객체 그래프 탐색이 가능한 모델을 가지면 도메인 모델
영화 예매라 시스템의 경우
논리적 도메인 구성
- 무비 + 디스카운트 + 룰은 연관 관계를 소유
- 무비는 디스카운트에 연관 관계가 없거나, 최대 1개만 존재한다.
- 디스카운트는 무비에 1개의 연관 관계가 존재한다.
- 디스카운트는 룰에 1개에서 *개 까지의 연관 관계가 존재한다.
- 룰은 디스카운트에 1개의 연관 관계가 존재한다.
- 논리적 모델
- 상영 정보 입력
- 연관 관계 조건 부합, 할인 결과 도메인 반환
- 여기까지가 논리적 시스템
- 이걸 어떻게 시스템 적으로 구현할까?
도메인 시스템 구현
- 영화를 예매 한다는 것은 실제적으로 상영 정보를 구입한다는 것
영화의 예매는 즉 상영 정보와 연관 관계를 가진다는 것을 의미, 최소 0개 최대 *개 - 영화 상영 정보가 없다면 예매 결과도 없으니 최소 0개 또는 *개
- 영화와 할인, 할인 룰은 영화가 예매되지 않더라도 존재하는 연관 관계
ERD (Entity Relationship Diagram)
- 객체들의 테이블이 이렇게 구성 되어 있고, 걔네들 간 pk는 fk는 어떻고 뭐 어쩌구저쩌구 이게 ERD
클래스 다이어그램
- ERD를 그대로 클래스 필드로 매핑하는 것 Anemic Domain Model이라 함
사진과 같이 각 클래스 별 상속에 따른 연관관계를 소유하는 것은 객체지향적 모델링 - 도메인에 맞는 객체 지향 클래스 구성이 이루어지면 도메인 모델링과 유사해짐
- 이렇게 만들어진 도메인 로직은 순수한 도메인 로직으로 DB에 어떻게 데이터를 넣고, 가져오고 알림을 메일로 보낼지 카카오톡 알림을 보낼지 등에 대한 어플리케이션 로직이 없음
트랜잭션 스크립트의 경우 로직 구성
- DB 읽고, 전처리 하고, 메일 보내고, 계산하고 전부 들어가 있음
객체 지향의 경우 로직 구성
- 할인 클래스
- 할인 룰 인터페이스
- 할인 룰 을 구현하는 시퀀스 룰 클래스
- 할인 룰을 구현하는 타임 룰 클래스
객체지향 모델링의 경우, 중복할인 클래스
- 할인을 적용하는 클래스가 있다면 그 클래스를 상속하는 클래스를 하나만 더 만들면 됨
- 기존의 코드를 변경하지 않고 상속받아 중복할인 클래스 제공
ATM