[OOP]애플리케이션 아키텍처와 객체지향
[KSUG Seminar] Growing Application - 2nd. 애플리케이션 아키텍처와 객체지향
레이어 아키텍처
- Presentation - Service - Domain - Data Source
도메인 레이어를 설계하는 방법
절차지향 (Transaction Script Pattern)
객체지향 (Domain Model Pattern)
도메인 레이어가 전체 아키텍처 구성을 주도
- 도메인 레이어를 절차지향이냐, 객체지향이냐에 따라 구성이 달라짐
절차 지향
Anemic Domain Model: Table의 속성을 그대로 객체로 매핑- Table 속성을 그대로 가지고 온 객체에 1:1로 DAO 객체를 만듦
- 실제로 짤 때 절차지향으로 짜는게 나은 경우도 있음
Domain Model
- 객체 지향적으로 짜는 것 : 프로세스와 데이터를 하나의 덩어리로 생각
- 객체지향 설계 : 협력하는 객체들의 공동체
- 주어진 책임을 수행하는 객체들의 협력
도메인 레이어와 아키텍처
- 도메인 로직을 처리하기 위한 전후 작업 필요 : DB read, DB write / 카톡, 문자 알림 등
어플리케이션 로직- 순수한 도메인 로직이 아닌, 도메인 로직의 전후 관계 전체 플로우를 관리
- 일반적으로 도메인 객체 안에 넣지 않음 : 의존성이 생기기 때문
- 결합도 높아지고 응집도 높아지기 때문
도메인 레이어 캡슐화
- 도메인 레이어 캡슐화를 위해
Service레이어 사용
서비스 레이어
- 애플리케이션 경계
- 애플리케이션 로직
- 도메인 로직의 재사용성 촉진
- 트랜잭션 바운더리 결정
트랜잭션 스크립트 사용시
- 트랜잭션 관리 + 애플리케이션 로직 + 도메인 로직 혼합
데이터 소스 레이어는 일반적으로 관계형 데이터 베이스
도메일 모델 사용 시
- 데이터 매핑이 어려움
- 객체-관계 임피던스 불일치
- 객체 모델과 DB 스키마 사이의 불일치
- 객체 패러다임과 관계 패러다임 간의 불일치
- 임피던스 불일치 해결을 위해
데이터 매퍼를 사용- JPA
트랜잭션 스크립트 사용 시
- 데이터와 처리가 나뉨
- 테이블과 1:1 매핑되는 Anemic Domain Model을 정의
- 하나의 객체가 DAO 처리
테이블 데이터 게이트웨이- 단일 테이블 또는 뷰에 접속하는 SQL 처리
- 도메인 레이어를 트랜잭션 스크립트로 구성하는 경우 사용
- DAO
What이 아니라 How를 봐야지만 도메인 개념 유추 가능. → 트랜잭션 스크립트에서 발생하는 문제점
선택의 기로
객체 지향의 장점
- 기존 코드를 수정하지 않고 새로운 클래스를 추가 : OCP
- OCP가 돌아갈 수 있는 가장 기본적인 이유 : 추상화를 기준으로 분리
- DIP : 추상에 의존
도메인 모델이 적합할 때
도메인 모델은 복잡성을 알고리즘에서 분리하고 객체 간의 관계로 만들 수 있다.
유효성 검사, 계산, 파생 등이 포함된
복잡하고끊임없이 변하는비즈니스 규칙을 구현해야 한다면 객체 모델을 사용해 비즈니스 규칙을 처리하는 것이 현명하다.<마틴 파울러>
