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

[KSUG Seminar] Growing Application - 2nd. 애플리케이션 아키텍처와 객체지향

레이어 아키텍처

  • Presentation - Service - Domain - Data Source

도메인 레이어를 설계하는 방법

  1. 절차지향 (Transaction Script Pattern)

  2. 객체지향 (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

Domain Model vs Transaction Script



What이 아니라 How를 봐야지만 도메인 개념 유추 가능. → 트랜잭션 스크립트에서 발생하는 문제점

선택의 기로

객체 지향의 장점

  • 기존 코드를 수정하지 않고 새로운 클래스를 추가 : OCP
  • OCP가 돌아갈 수 있는 가장 기본적인 이유 : 추상화를 기준으로 분리
    • DIP : 추상에 의존

도메인 모델이 적합할 때

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

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

<마틴 파울러>

변경이 발생할 때 마다 리팩토링!

참조