도메인 논리 구성

도메인 로직을 조직화하는 데는 세 가지 주요 패턴이 있다: 트랜잭션 스크립트(Transaction Script), 도메인 모델(Domain Model), 테이블 모듈(Table Module).

트랜잭션 스크립트 (Transaction Script)

가장 간단한 접근 방식은 트랜잭션 스크립트(Transaction Script)이다. 트랜잭션 스크립트는 프레젠테이션에서 입력을 받아 유효성 검사와 계산을 수행하고, 데이터를 데이터베이스에 저장하며, 다른 시스템의 작업을 호출하는 절차이다. 그런 다음 응답 데이터를 프레젠테이션에 반환하면서 추가 계산을 수행하여 응답을 조직하고 형식화한다. 트랜잭션 스크립트는 사용자가 수행하려는 각 작업에 대한 단일 절차로 구성된다. 소매 시스템에서는 결제, 장바구니에 물건 추가, 배송 상태 표시 등의 트랜잭션 스크립트를 가질 수 있다.

트랜잭션 스크립트의 장점

  • 대부분의 개발자가 이해하기 쉬운 단순한 절차적 모델이다.

  • Row Data Gateway 또는 Table Data Gateway를 사용하는 간단한 데이터 소스 레이어와 잘 작동한다.

  • 트랜잭션 경계를 설정하는 것이 명확하다: 트랜잭션을 시작하고 종료하는 것으로 시작하며, 도구가 이를 자동으로 처리하기 쉽다.

트랜잭션 스크립트의 단점

  • 도메인 로직의 복잡성이 증가할수록 코드 중복이 발생할 가능성이 높다.

  • 여러 트랜잭션이 유사한 작업을 수행해야 할 때 중복 코드를 제거하기 어렵다.

  • 결과적으로 명확한 구조 없이 얽힌 루틴의 복잡한 웹이 될 수 있다.

도메인 모델 (Domain Model)

복잡한 로직을 처리하는 객체 지향 방식은 도메인 모델(Domain Model)이다. 도메인 모델은 도메인의 명사를 중심으로 모델을 구축하며, 예를 들어 리스팅 시스템에는 리스, 자산 등의 클래스가 있을 수 있다. 유효성 검사와 계산을 처리하는 로직은 이 도메인 모델에 위치하며, 예를 들어 배송 객체는 배송 요금을 계산하는 로직을 포함할 수 있다.

도메인 모델의 장점

  • 도메인 로직이 분산되어 있어 코드 중복이 줄어든다.

  • 객체 지향 패러다임의 전환으로 복잡한 로직을 보다 잘 조직화할 수 있다.

  • 새로운 알고리즘을 추가할 때 더 쉽게 확장할 수 있다.

도메인 모델의 단점

  • 복잡한 데이터 소스 레이어와 함께 사용하기 어려울 수 있다.

  • 리치 객체 모델에 익숙해지는 데 시간이 걸릴 수 있다.

  • 데이터베이스 매핑이 더 복잡해질 수 있다.

테이블 모듈 (Table Module)

테이블 모듈(Table Module)은 계약, 제품, 수익 인식을 위한 클래스를 가지지만, 도메인 모델과 달리 데이터베이스의 각 계약에 대한 인스턴스를 하나만 가진다. 테이블 모듈은 레코드 셋(Record Set)과 함께 작동하도록 설계되었으며, 클라이언트는 데이터베이스에 쿼리를 발행하여 레코드 셋을 형성하고 이를 계약 객체에 전달한다. 그런 다음 클라이언트는 계약 객체에서 다양한 작업을 수행할 수 있다.

테이블 모듈의 장점

  • 테이블을 중심으로 도메인 로직을 조직화하여 더 많은 구조를 제공하고 코드 중복을 제거하기 쉽다.

  • SQL 쿼리 결과와 함께 작동하므로, GUI 환경과 쉽게 통합할 수 있다.

  • .NET이나 Visual Studio와 같은 환경에서는 더 매력적이다.

테이블 모듈의 단점

  • 객체 지향 패턴의 세밀한 구조를 사용할 수 없다.

  • 특정 환경에서만 유용할 수 있다.

선택하기

세 가지 패턴 중에서 선택하는 것은 쉬운 일이 아니며, 도메인 로직의 복잡성에 크게 좌우된다. 단순한 도메인 로직에서는 트랜잭션 스크립트가 더 적합할 수 있지만, 복잡성이 증가할수록 도메인 모델이나 테이블 모듈이 더 유리할 수 있다.

도메인 모델을 선택해야 하는 경우

  • 도메인 로직의 복잡성이 높을 때

  • 팀이 도메인 모델에 익숙한 경우

  • 복잡한 데이터를 다루는 경우

테이블 모듈을 선택해야 하는 경우

  • SQL 쿼리 결과와 잘 맞는 환경인 경우

  • GUI 환경과 쉽게 통합할 수 있는 경우

트랜잭션 스크립트를 선택해야 하는 경우

  • 도메인 로직이 단순한 경우

  • 코드 중복이 문제가 되지 않는 경우

서비스 레이어 (Service Layer)

도메인 로직을 처리하는 일반적인 접근 방식은 도메인 레이어를 두 부분으로 나누는 것이다. 서비스 레이어(Service Layer)는 도메인 모델 또는 테이블 모듈 위에 위치하며, 프레젠테이션 로직은 순수하게 서비스 레이어를 통해 도메인과 상호작용한다. 서비스 레이어는 트랜잭션 제어와 보안과 같은 기능을 제공하기에도 좋은 위치이다.

서비스 레이어는 API를 제공하며, 트랜잭션 래퍼와 보안 검사를 추가하기 좋은 지점이다. 서비스 레이어에 얼마나 많은 로직을 넣을지는 상황에 따라 다르지만, 가능한 얇은 서비스 레이어를 유지하는 것이 좋다.

결론적으로, 도메인 로직을 조직화하는 세 가지 주요 패턴인 트랜잭션 스크립트, 도메인 모델, 테이블 모듈 중에서 애플리케이션의 요구 사항과 팀의 경험에 따라 적절한 패턴을 선택하는 것이 중요하다. 각 패턴은 고유한 장점과 단점을 가지고 있으며, 상황에 맞게 적절히 조합하여 사용할 수도 있다.

Last updated