09장 도메인 논리 패턴

트랜잭션 스크립트

• 비즈니스 논리를 프로시저별로 구성해 각 프로시저가 프레젠테이션의 단일 요청을 처리하게 한다.

작동 원리

• 트랜잭션 스크립트를 사용하는 경우 도메인 논리는 주로 시스템에 대해 수행하는 트랜잭션으로 구성된다.
• 이 방식의 장점 중 하나는 다른 트랜잭션에서 하는 일에 대해 신경 쓸 필요가 없다는 것이다.
  • 입력을 받고, 데이터베이스에서 정보를 얻고, 필요한 작업을 한 후, 결과를 데이터베이스에 저장하면 된다.
• 트랜잭션 스크립트는 최대한 분리하는 것이 좋다.
  • 적어도 별도의 서브루틴에 넣어야 하며, 프레젠테이션과 데이터 원본을 처리하는 클래스와는 다른 클래스에 넣는 것이 좋다.
  • 트랜잭션 스크립트에는 프레젠테이션 논리에 대한 호출을 전혀 포함하지 말아야 한다.

사용 시점

• 트랜잭션 스크립트의 가장 큰 장점은 단순함이다.
• 작은 규모의 논리가 포함된 애플리케이션에서 자연스럽게 논리를 구성할 수 있는 방법이며, 코드를 실행할 때 발생하는 오버헤드가 적고 코드를 이해하기 쉽다.
• 하지만 비즈니스가 논리가 복잡해지면 좋은 설계 상태를 유지하기가 점차 어려워지고, 트랜잭션 간의 코드 중복이 발생한다.
  • 규칙이 복잡해지면 해결하는 방벙블 찾기 어렵다.
  • 복잡한 비즈니스 도메인을 구현할 때는 도메인 모델을 이용하는 것이 좋다.

도메인 모델

• 도메인 모델은 규칙과 논리는 매우 다양한 사례와 동작의 변형을 나타내며, 객체는 이러한 복잡성을 처리하기 위해 고안됐다.
• 도메인 모델은 의미있는 하나의 대상을 나타내는 상호 연결된 객체의 연결망으로 이뤄진다.

작동 원리

• 애플리케이션에서 도메인 모델을 구현하는 과정은 비즈니스 영역을 모델링하는 객체로 구성된 계층을 구성하는 과정이다.
• 객체 중에는 일상적인 업무에 사용되는 비즈니스 데이터를 나타내는 객체도 있고 비즈니스 규칙을 나타내는 객체도 있다.
• 단순 도메인 모델은 대부분의 도메인 객체가 각 데이터베이스 테이블과 일치하므로 외형상 데이터베이스 설계와 거의 비슷해 보인다.
• 리치 도메인 모델은 상속, 전략, 다양한 패턴, 그리고 복잡한 상호 연결된 객체의 연결망을 포함하므로 데이터베이스 설계와는 상당히 다르게 보일 수 있다.
  • 리치 도메인 모델은 복잡한 논리를 나타내는 데 적합하지만 데이터베이스에 매핑하기는 더 어렵다.
• 도메인 모델은 시스템의 다른 계창 간의 결합을 최소화해야 한다.

자바 구현

• POJO 도메인 모델은 이해하기 쉽고, 빠르게 만들 수 있으며, EJB 컨테이너 외부에서 실행 및 테스트할 수 있고, EJB에 대해 독립적이다.
• 상속, 전략, 그밖의 다른 정교한 패턴 등이 포함된 복잡한 도메인 논리를 구축하려면 상업용 툴이나 직접 제작한 계층을 활용해 POJO 도메인 모델과 데이터 매퍼를 만드는 것이 좋다.

사용 시점

• 복잡하고 끊임없이 변하는 비즈니스 규칙을 구현해야 한다면 객체 모델을 사용해 비즈니스 규칙을 처리하는 것이 현명하다.
• 간단한 null 검사, 간단한 합계 계산 등이 전부라면 트랜잭션 스크립트가 더 나은 선택이다.

테이블 모듈

• 데이터베이스 테이블이나 뷰의 모든 행에 대한 비즈니스 논리를 처리하는 단일 인스턴스
• 객체지향의 핵심 개념 중 하나는 데이터, 그리고 이를 사용하는 동작을 하나로 묶는 것이다.
• 도메인 모델의 문제점 중 하나는 관계형 데이터베이스와의 인터페이스가 까다롭다는 것이다.
• 테이블 모듈은 데이터베이스의 테이블당 클래스 하나로 도메인 논리를 구성하며, 클래스의 한 인스턴스가 해당 데이터에 대해 수행하는 여러 프로시저를 포함한다.
  • 도메인 모듈과 가장 큰 차이점은 주문이 여러 개인 경우 도메인 모델은 주문의 수만큼 객체르 ㄹ사용하지만, 테이블 모듈은 모든 주문을 객체 하나가 처리한다는 것이다.

작동 원리

• 테이블 모듈의 장점은 데이터와 동작을 하나로 묶으면서도 동시에 관계형 데이터베이스의 강력함을 그대로 활용할 수 있다는 것이다.
• 동작을 테이블과 함께 그룹화함으로써 동작과 이 동작의 대상이 되는 데이터를 하나로 묶는 캡슐화의 려어 장점을 제공할 수 있게 된다.
• 테이블 모듈은 인스턴스 하나이거나 정적 메서드의 컬렉션일 수 있다.
• 테이블 모듈은 쿼리를 팩터리 메서드로서 포함할 수 있다.

사용 시점

• 테이블 모듈은 그 이름이 나타내는 것처럼 레코드 집합을 사용해 테이블 형식의 데이터에 접근할 때 가장 적합한 패턴이다.
• 또한 자료구조를 코드에서 가장 중요한 요소로 다루므로 자료 구조에 직관적으로 접근할 수 있다.
• 직접적인 인스턴스-인스턴스 관계를 만들 수 없고, 다형성이 제대로 작동하지 않는다.
  • 따라서 복잡한 도메인 논리를 처리해야 한다면 도메인 모듈을 선택하는 것이 더 좋다.

서비스 계층

• 사용 가능한 작업의 집합을 설정하고 각 작업에 대한 애플리케이션의 반응을 조율하는 서비스의 계층으로 애플리케이션의 경계를 정의한다.
• 서비스 계층은 작업을 구현할 때 트랜잭션을 제어하며 응답을 조율하면서 애플리케이션의 비즈니스 논리를 캡슐화한다.

작동 원리

• 비즈니스 논리
  • 서비스 계층은 트랜잭션 스크립트나 도메인 모델과 마찬가지로 비즈니스 논리를 구성하기 위한 패턴이다.
  • 도메인 논리는 순수하게 문제 도메인을 집중적으로 처리하며, 애플리케이션 논리는 애플리케이션 역할을 처리한다.
• 애플리케이션 논리를 순수 도메인 객체 클래스에 넣으면 두 가지 부작용이 있다.
  • 도메인 객체 클래스가 특정 애플리케이션 논리를 구현하고 특정 애플리케이션 패키지를 사용하면 도메인 객체 클래스를 다른 애플리케이션에서 재사용하기 어려워진다.
• 구현의 변형
  • 도메인 파사드 방식과 작업 스크립트 방식이 있다.
  • 도메인 파사드 방식에서는 서비스 계층을 도메인 모델 위에서 씬 파사드의 집합으로 구현된다.

사용 시점

• 서비스 계층의 장점은 여러 종류의 클라이언트에 제공하는 애플리케이션 작업의 공통적인 집합을 정의하고 각 작업에 대한 애플리케이션의 응답을 조율한다.

 

---

핵심용어정리

-

 

---

참고자료

 

https://www.ypbooks.co.kr/book.yp?bookcd=100640948&gubun=NV&NaPm=ct%3Dldwj6stc%7Cci%3D8251fe3a560ebe2484e609d1e6279a7f7ec452ab%7Ctr%3Dboksl1%7Csn%3D5295494%7Chk%3Da517eb77dacef8bd533983ee170a3599fbba8bb6

영풍문고 - 서점다운 서점