도메인 논리 패턴
도메인 로직 패턴은 비즈니스 로직을 구조화하는 데 중요한 역할을 하며, 엔터프라이즈 애플리케이션 설계에서 다양한 상황에 맞게 선택될 수 있습니다.
1. 트랜잭션 스크립트 (Transaction Script)
트랜잭션 스크립트는 비즈니스 로직을 각각의 트랜잭션 단위로 절차적으로 구현하는 패턴입니다. 여기서 각 트랜잭션은 독립적인 스크립트나 함수로 처리되며, 이 스크립트는 데이터베이스와의 상호작용을 담당합니다. 이 패턴은 비즈니스 애플리케이션에서 발생하는 각 트랜잭션의 로직을 단일 프로시저에 캡슐화하여 처리합니다.
특징:
비즈니스 로직을 각 트랜잭션 단위로 조직화합니다.
시스템의 다른 트랜잭션과 관계없이 특정 트랜잭션을 독립적으로 처리할 수 있습니다.
단순한 구조로 인해 코드 작성이 용이하며, 특히 간단한 애플리케이션에 적합합니다.
예시:
호텔 예약 시스템에서, 방의 가용성을 확인하고, 요금을 계산하며, 결과를 데이터베이스에 업데이트하는 모든 로직이 하나의 스크립트 내에 포함될 수 있습니다.
수익 인식(revenue recognition) 문제를 해결하기 위해 각 계약에 대한 수익을 특정 날짜에 인식하는 로직이 각각의 트랜잭션 스크립트로 구현됩니다.
장점:
단순한 구조로 인해 개발 속도가 빠르며, 코드가 간결하고 직관적입니다.
각 트랜잭션을 독립적으로 처리하므로 테스트와 디버깅이 용이합니다.
단점:
로직이 복잡해질수록 코드 중복이 발생하기 쉽고 유지보수가 어려워질 수 있습니다.
공통의 하위 작업이 여러 트랜잭션에 걸쳐 중복될 경우, 코드 일관성을 유지하기 어렵습니다.
트랜잭션 스크립트는 비즈니스 로직이 단순한 애플리케이션에서 효과적입니다. 그러나 비즈니스 로직이 복잡해지거나 여러 트랜잭션 간의 중복이 많아질 경우, 도메인 모델과 같은 더 복잡한 패턴으로 전환하는 것이 좋습니다.
2. 도메인 모델 (Domain Model)
도메인 모델은 객체 지향 설계를 기반으로 하여, 비즈니스 로직과 데이터를 하나의 객체로 캡슐화하는 패턴입니다. 도메인 모델은 복잡한 비즈니스 로직을 다루는 데 적합하며, 객체 간의 상호작용을 통해 다양한 비즈니스 규칙을 구현할 수 있습니다.
특징:
객체 지향 모델링을 통해 비즈니스 도메인을 표현하며, 객체는 데이터와 행동(메소드)을 포함합니다.
도메인 모델은 상속, 다형성(polymorphism), 관계 등 객체 지향의 다양한 개념을 활용할 수 있습니다.
도메인 모델은 객체 간의 복잡한 관계와 상호작용을 쉽게 표현할 수 있으며, 비즈니스 로직을 효과적으로 관리할 수 있습니다.
예시:
수익 인식 문제를 해결할 때, 도메인 모델은 계약과 수익 인식 객체를 정의하여, 각 객체가 특정 날짜에 수익을 인식할 수 있는지 여부를 판단하는 로직을 포함합니다.
예를 들어, 특정 제품의 유형에 따라 다른 수익 인식 알고리즘을 적용할 수 있도록 전략 패턴(Strategy Pattern)을 활용합니다.
장점:
복잡한 비즈니스 로직을 구조화하여 관리할 수 있으며, 중복된 로직을 줄이고 코드의 가독성을 높일 수 있습니다.
객체 지향 설계의 장점을 최대한 활용할 수 있으며, 재사용성과 유지보수성이 뛰어납니다.
단점:
구현이 복잡하며, 특히 도메인 모델과 관계형 데이터베이스 간의 매핑이 어려울 수 있습니다.
높은 학습 곡선이 요구되며, 잘못된 구현은 오히려 시스템의 복잡성을 증가시킬 수 있습니다.
도메인 모델은 복잡한 비즈니스 로직과 상호작용을 관리하는 데 탁월한 패턴입니다. 특히, 비즈니스 규칙이 자주 변경되거나 복잡한 경우에 도메인 모델을 사용하는 것이 좋습니다. 그러나 도메인 모델을 효과적으로 사용하려면 높은 수준의 객체 지향 설계 능력이 필요하며, 이를 위해 많은 연습과 경험이 요구됩니다.
3. 테이블 모듈 (Table Module)
테이블 모듈은 데이터베이스의 각 테이블에 대해 하나의 클래스를 정의하고, 그 클래스가 해당 테이블의 모든 행(row)에 대한 비즈니스 로직을 처리하는 패턴입니다. 이 패턴은 주로 테이블 기반 데이터 구조를 사용하는 환경에서 적합합니다.
특징:
각 테이블에 대해 하나의 클래스가 있으며, 이 클래스는 테이블의 모든 행에 대한 작업을 처리합니다.
테이블 모듈은 테이블 지향 데이터 구조를 중심으로 비즈니스 로직을 구성합니다.
주로 데이터 집합(Record Set)을 사용하여 테이블 지향 데이터를 관리합니다.
예시:
수익 인식 문제에서 테이블 모듈 패턴을 사용하는 경우, 각 계약에 대한 수익 인식을 계산하는 로직을 계약 테이블과 관련된 클래스에 포함시킵니다. 이 클래스는 계약에 따른 수익을 계산하고, 결과를 데이터베이스의 수익 인식 테이블에 기록합니다.
장점:
데이터베이스와의 통합이 용이하며, 테이블 지향 데이터 구조를 중심으로 설계된 애플리케이션에서 특히 유용합니다.
여러 테이블 모듈이 하나의 데이터 집합을 공유하여 작업할 수 있으며, 이를 통해 코드의 재사용성과 유지보수성을 높일 수 있습니다.
단점:
객체 간의 복잡한 관계를 다루기 어렵고, 다형성(polymorphism)을 제대로 활용하기 어려워 복잡한 비즈니스 로직을 처리하는 데 한계가 있습니다.
객체 간의 직접적인 상호작용을 필요로 하는 복잡한 도메인 로직을 처리할 때는 도메인 모델이 더 적합할 수 있습니다.
테이블 모듈 패턴은 데이터가 주로 테이블 형식으로 저장되고, 이러한 데이터에 대한 처리가 상대적으로 단순한 경우에 적합합니다. 특히, .NET 환경에서 데이터 집합을 중심으로 설계된 애플리케이션에 적합하며, 복잡한 객체 간 관계보다는 테이블 간의 데이터 처리가 중심이 되는 경우 유용합니다.
4. 서비스 레이어 (Service Layer)
서비스 레이어는 애플리케이션의 경계를 정의하고, 클라이언트가 사용할 수 있는 일련의 운영(Operation)을 제공하는 패턴입니다. 서비스 레이어는 애플리케이션의 비즈니스 로직을 캡슐화하며, 트랜잭션 관리 및 응답 조정을 포함하여 애플리케이션의 다양한 요구를 처리합니다.
특징:
클라이언트 계층과의 인터페이스로서, 애플리케이션의 비즈니스 로직을 실행하고 응답을 조정합니다.
서비스 레이어는 도메인 로직과 애플리케이션 로직을 분리하여, 도메인 객체가 보다 재사용 가능하게 설계될 수 있도록 합니다.
서비스 레이어는 주로 두 가지 구현 방식으로 나뉩니다: 도메인 퍼사드(domain facade) 접근 방식과 운영 스크립트(operation script) 접근 방식입니다.
도메인 퍼사드 접근 방식: 서비스 레이어는 도메인 모델 위에 얇은 퍼사드로 구현되며, 실제 비즈니스 로직은 도메인 모델이 처리합니다.
운영 스크립트 접근 방식: 서비스 레이어는 두꺼운 클래스 집합으로 구성되며, 각 클래스는 관련 로직의 주제 영역을 정의합니다. 이 클래스들은 애플리케이션 로직을 직접 구현하며, 도메인 객체 클래스에 도메인 로직을 위임합니다.
예시:
수익 인식 문제
에서 서비스 레이어를 사용하는 경우, 수익 인식 계산 후 계약 관리자에게 이메일을 보내고, 메시지 지향 미들웨어(MOM)를 통해 다른 애플리케이션에 알리는 작업을 처리합니다. 이 서비스 레이어는 운영 스크립트 접근 방식을 사용하여, 도메인 로직은 도메인 객체에 위임하고, 애플리케이션 로직은 서비스 레이어에서 처리합니다.
장점:
여러 종류의 클라이언트를 지원할 수 있으며, 복잡한 트랜잭션 관리가 필요한 애플리케이션에서 유용합니다.
서비스 레이어를 통해 트랜잭션 관리 및 응답 조정을 중앙 집중화할 수 있습니다.
특히, EJB(Enterprise JavaBeans)와 같은 컨테이너 관리 트랜잭션을 사용할 때, 분산 트랜잭션 관리가 용이합니다.
단점:
애플리케이션이 단일 클라이언트와 단순한 트랜잭션 리소스를 사용하는 경우, 서비스 레이어는 불필요하게 복잡해질 수 있습니다.
이 경우, 페이지 컨트롤러(Page Controller)가 트랜잭션을 직접 관리하고 응답을 조정할 수 있습니다.
서비스 레이어는 복잡한 비즈니스 로직과 여러 클라이언트를 지원해야 하는 애플리케이션에서 사용됩니다. 특히, 여러 트랜잭션 리소스를 사용하는 경우, 서비스 레이어를 통해 트랜잭션 관리를 중앙 집중화할 수 있습니다. EJB와 같은 컨테이너 관리 트랜잭션을 활용하여, 복잡한 트랜잭션 관리를 효과적으로 처리할 수 있습니다.
Last updated