애플리케이션 아키텍처와 객체지향

본 내용은 우아한 형제들의 조영호 개발실장님의

KSUG Seminar 강의 내용을 바탕으로 작성하였습니다.

관련 유튜브영상은  요기를 클릭해주세요

 

1.아케텍처

 

프로젝트에 참여하는 개발자들이

설계에 대해 공유하는 이해를 반영하는 주관적인 개념

중요한것. 변경하기 어려운것. 일찍,올바르게 결정하고 싶은거

서로 다르고 관련이 없는 책임들을 분리

 

 

 

 

 

 

2.도메인 레이어를 설계하는 방법(마틴 파울러)

 

1) 절차지향-transaction script

 

엔티티에는 비즈니스 로직이 거의 없고 서비스 계층에서 대부분의 로직을 처리하는 것을 트랜잭션 스크립트 패턴이라고한다.

내가 다뤄야할  데이터와 그 데이터를 조작하는  프로세스가 따로 움직인다.

로직이 서비스에서 처리되다보니 서비스 계층이 무의미, 엔티티란 단순히 데이터 덩어리 역할만하게됨

OOP 언어를 사용하고 클래스를 만들지만 사실은 여전히 구조적으로 프로그래밍을 하므로 로직과 데이터가 애플리케이션 전체적으로 분리되어 있다.

ERD->각각 class(필드,게터,세터)->각각 DAO생성->서비스 만들고 dao들 다 가져와서 injection 서비스에서 데이터 가져와서 작업 서비스에서 끝남

 

-테이블과 1:1 매핑되는 Anemic Domain Model

ERD->각각 class(필드,게터,세터)생성

단순 데이터 접근 메서드만 있는 도메인 모델

도메인 모델을 도입하는데 드는 비용만 들고 이점을 못누림

모든 로직은 서비스에 몰려 있음

 

-테이블 데이터 게이트 웨이

단일 테이블 또는 뷰에 접속하는 SQL 처리

도메일 레이어를 트랜잭션 스크립트로 구성하는 경우 사용

 DAO생성

 

시퀀스 다이어그램 그려봤을때 제어가 한쪽으로 몰리면 (중앙 집중식 제어 스타일)그건 절차지향 패턴임

 

service Layer에  트랜잭션관리+애플리케이션로직+도메인로직이 한꺼번에 다 있음.

 

2) 객체지향-domain model 

 

협력하는 객체들의 공동체 

주어진 책임을 수행하는 객체들의 협력(메세지 전송)

앤티티가 비즈니스 로직을 가지고 객체지향의 특성을 적극 활둉하는 것을 도메인 모델

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

시퀀스 다이어그램 그리면 위임식(delegated),분산식(dispersed) 제어스타일

 

 

 

(1)CRC card

책임과 협력을 표현하기 위한 객체지향 설계 도구

 

Candidate(Role or Object): 상영정보를 알고 있다.

Responsibility: 예매 정보를 생성한다

Collaborator: Movie

 

요구사항을 수행하기 가장 적절한 객체는 무엇이 있을까로 접근해야함

책임 맡을 객체 생성시 가장 많은 정보를 가지고 있을 전문가에게 책임할당하면됨

 

 

어플리케이션 로직은 도메인 로직의 전후 관계 플로우 관리

그래서 어플리케이션 로직이 도메인 로직속에 들어가면 의존성 생겨서 응집도 떨어지고 결합도 높아져서  도메인 레이어 캡슐화를 위해 따로 서비스 레이어를 만듬

 

서비스 레이어

1.애플리케이션 경계 2. 애플리케이션 로직(begin tx, commit) 3.도메인 로직의 재사용 촉진 

도메인 로직을 사용하기 위한 준비작업

도메인 로직의 결과,에러 후처리만 서비스 레이어담당.

예제에서 할인정책 알고싶으면 절차지향은 일일이 찾아 들어가야되지만 도메인모델은 도메인 모델만 들어가면됨.

 

 

3) 절차지향과 객체지향 선택

 

변하지 않는 것은 모든 것이 변한다는 사실뿐이다. -헬라클레이토스

요구사항도 변한다

할인 1개였는데 할인 중복으로 변경된다면???

 

-절차지향코드

기존코드 수정 두려움

암묵적인 개념-절차지향 사용시 중복할인이라는 개념이 암묵적으로 숨어버림

 

-객체지향코드

컴포지트 디자인 패턴

무비입장에서 하나의 할인이나 여러개의 할인이나 같음

암묵적인 개념이 명시적으로 표현됨

기존 코드를 수정하지 않고 새로운 클래스를 추가

개방폐쇄 원칙 (OCP Open-Closed Principle)

수정에는 닫혀있지만 행동을 변경하거나 확장하는거에는 열려있음

 

 

High Level Module —>High Level Module

                                      ㅅ

                                        I

                                     Low-Level Module

의존성의 방향이 추상화 쪽으로  흐름. 

Dependency -Inversion Principle DIP 즉 의존성 역전 원칙이라함

 

 

-추상화를 이용한 효율적인 커뮤니케이션

추상화를 하면 중요한것. 변경하기 어려운곳. 일찍,올바르게 결정하고 싶은것이됨

Domain Abstraction —> Domain Layer Architecture  가됨

[도메인 모델은] 복잡성을 알고리즘에서 분리하고 객체 간의 관계로 만들 수 있다.

유효성 검사, 계산, 등이 포함된 복잡하고 끊임없이 변하는 비즈니스 규칙을 구현해야 한다면 객체 모델을 사용해 비즈니스 규칙을 처리하는 것이 현명하다 -마틴 파울러-

 

 

클래스의 개수가 작고 커지는 거보다 클래스가 작고 갯수가 많아지는게 좋다

알고리즘은 절차지향이 좋다

 

 

 

-예시 요구사항

 

영화

상영

할인정책: 얼마만큼빼줄건지

할인규칙:언제 어떤조건 만족시 예매금액할인해줄건지

 

상영   1— 0..* 예약

I  0..*

I

I  1

영화1   0..1- 디스카운트1- 1..* 룰