종합
도메인 레이어 선택
엔터프라이즈 애플리케이션 설계에서 가장 중요한 첫 번째 결정은 도메인 로직을 어떻게 구현할 것인지 결정하는 것입니다. 이 과정에서 세 가지 주요 패턴이 논의됩니다: 트랜잭션 스크립트, 테이블 모듈, 도메인 모델입니다.
트랜잭션 스크립트 (Transaction Script, 110):
특징: 트랜잭션 스크립트는 시스템의 각 트랜잭션 로직을 하나의 스크립트로 캡슐화하여 구현합니다. 이 패턴은 절차적(Procedural) 모델에 익숙한 개발자들에게 친숙하며, 로직을 명확하게 이해할 수 있도록 구조화합니다.
장점: 데이터베이스와의 통합이 용이하며, 단순한 로직을 처리하기에 적합합니다. 예를 들어, 쇼핑 카트와 같은 간단한 애플리케이션에서는 매우 효과적으로 사용할 수 있습니다.
단점: 복잡한 비즈니스 로직을 처리하는 데 취약합니다. 코드 중복이 발생하기 쉽고, 로직이 복잡해질수록 문제도 비례적으로 증가합니다. 복잡한 애플리케이션에는 적합하지 않습니다.
도메인 모델 (Domain Model, 116):
특징: 도메인 모델은 객체 지향 설계를 기반으로 하여 복잡한 비즈니스 로직을 효율적으로 처리할 수 있습니다. 객체의 상호작용을 통해 로직을 표현하며, 이러한 객체 모델은 비즈니스 로직의 복잡성을 반영합니다.
장점: 매우 복잡한 도메인 로직을 효과적으로 다룰 수 있습니다. 도메인 모델을 사용하면 간단한 문제도 객체 모델을 통해 쉽게 해결할 수 있습니다. 실제로 복잡한 엔터프라이즈 애플리케이션에서는 도메인 모델이 가장 강력한 패턴입니다.
단점: 도메인 모델을 학습하고 효과적으로 사용하는 데 높은 숙련도가 필요합니다. 잘못된 구현은 오히려 문제를 악화시킬 수 있습니다. 또한, 도메인 모델과 관계형 데이터베이스 간의 매핑이 복잡해질 수 있습니다. 객체 모델과 관계형 데이터 모델이 자연스럽게 일치하지 않기 때문에 O/R 매핑의 복잡성이 크게 증가합니다.
테이블 모듈 (Table Module, 125):
특징: 테이블 모듈은 트랜잭션 스크립트와 도메인 모델의 중간에 위치한 패턴입니다. 이 패턴은 테이블별로 클래스를 정의하고, 테이블에 저장된 데이터를 처리하는 모든 로직을 이 클래스에 포함시킵니다.
장점: 도메인 로직을 보다 체계적으로 관리할 수 있으며, 관계형 데이터베이스와의 통합이 용이합니다. .NET 환경에서 특히 유용한데, 이는 많은 도구들이 이 패턴에 맞춰 설계되어 있기 때문입니다. 복잡한 로직을 처리하는 데 있어서 도메인 모델만큼 강력하지는 않지만, 도메인 로직을 어느 정도 처리할 수 있습니다.
단점: 도메인 모델만큼 복잡한 로직을 다룰 수는 없습니다. 테이블 모듈 패턴은 단순한 데이터 조작에 유리하지만, 복잡한 비즈니스 로직이 포함된 경우 도메인 모델이 필요할 수 있습니다.
데이터 소스 레이어 연결
도메인 레이어를 선택한 후에는 이 레이어를 데이터 소스에 어떻게 연결할지를 결정해야 합니다. 여기서도 도메인 레이어의 선택에 따라 데이터 소스 연결 방식이 달라집니다.
트랜잭션 스크립트:
트랜잭션 스크립트는 가장 간단한 구현 방식으로, 데이터베이스 로직을 스크립트에 직접 포함시킬 수 있습니다. 그러나 저자는 데이터베이스 로직을 별도의 계층으로 분리할 것을 권장합니다.
Row Data Gateway(152)와Table Data Gateway(144)중 하나를 선택하여 데이터베이스와의 연결을 처리할 수 있습니다.Row Data Gateway는 각 레코드를 개별 객체로 읽어와 명시적 인터페이스를 제공합니다. 이 방식은 코드가 명확하고 유지보수가 용이하지만, 구현해야 할 코드가 많아질 수 있습니다.
Table Data Gateway는 코드 작성이 상대적으로 간단하며, 레코드 셋 구조에 직접 접근할 수 있는 장점이 있습니다. 이는 많은 UI 도구들과 잘 맞으며, 트랜잭션 스크립트를 사용하는 환경에서는 적합한 선택이 될 수 있습니다.
동시성 문제는 일반적으로 스크립트 자체에서 쉽게 처리할 수 있으나, 여러 요청 간 데이터 일관성을 유지해야 하는 경우
Optimistic Offline Lock(416)을 사용할 수 있습니다.
테이블 모듈:
테이블 모듈 패턴을 사용할 때는 주로
Table Data Gateway(144)를 데이터 소스 패턴으로 사용합니다. 이 패턴은Record Set(508)과 매우 잘 맞으며, 이 둘은 자연스럽게 함께 사용됩니다.동시성 제어가 필요할 경우,
Record Set(508)자체에 내장된 메커니즘을 사용할 수 있습니다. 이는Unit of Work(184)패턴과 유사한 역할을 하며, 데이터 변경 사항을 관리할 수 있습니다.
도메인 모델:
도메인 모델이 단순할 경우
Active Record(160)패턴을 사용하여 각 객체가 스스로의 데이터를 데이터베이스에 저장하거나 불러올 수 있도록 합니다. 이 방식은 도메인 모델과 데이터베이스 간의 매핑을 쉽게 처리할 수 있습니다.도메인 모델이 복잡해질 경우
Data Mapper(165)패턴을 사용하여 도메인 모델을 데이터베이스로부터 완전히 독립시킬 수 있습니다. 이 방식은 더 복잡하지만, 도메인 모델을 보다 유연하게 관리할 수 있습니다. 대부분의 O/R 매핑 패턴은 이 상황에서 적용될 수 있으며, 특히Unit of Work(184)패턴은 동시성 제어의 중심이 됩니다.
프레젠테이션 레이어 설계
프레젠테이션 레이어는 엔터프라이즈 애플리케이션의 사용자 인터페이스를 정의하는 부분으로, 도메인 레이어 및 데이터 소스 레이어와 비교적 독립적으로 설계될 수 있습니다. 이 레이어에서는 리치 클라이언트와 HTML 브라우저 인터페이스 중에서 선택해야 합니다.
리치 클라이언트:
리치 클라이언트는 UI가 더 풍부하고 정교하며, 사용자가 더 직관적인 인터페이스를 사용할 수 있습니다. 그러나 클라이언트의 배포와 관리를 필요로 합니다. 복잡한 비즈니스 애플리케이션에서 유용할 수 있습니다.
HTML 브라우저:
HTML 브라우저 인터페이스는 배포가 간편하며, 클라이언트 환경에 독립적입니다. 저자는 가능한 경우 HTML 브라우저를 선택할 것을 권장합니다. 웹 기반 애플리케이션에서 흔히 사용되며,
Model View Controller(330)패턴을 기반으로 설계할 수 있습니다.페이지 구조가 단순하고 문서 중심일 경우
Page Controller(333)를, 복잡한 네비게이션과 UI가 필요할 경우Front Controller(344)를 선택할 수 있습니다.뷰(View)에서는
Template View(350)패턴을 기본적으로 사용하며, XML 변환이 필요한 경우Transform View(361)를 사용할 수 있습니다. 여러 가지 형태의 뷰를 제공해야 할 경우Two Step View(365)패턴을 고려할 수 있습니다.
기술별 조언
특정 기술 플랫폼에 따라 패턴의 선택과 사용 방식이 달라질 수 있습니다. 여기서는 Java와 .NET에 대한 구체적인 조언을 다룹니다.
Java:
Java 환경에서는 EJB(Enterprise JavaBeans)의 사용 여부가 중요한 결정 사항입니다. EJB를 사용할 경우 세션 빈(Session Bean)을 트랜잭션 스크립트로, 엔터프라이즈 빈(Entity Bean)을
Row Data Gateway(152)로 사용하는 것이 일반적입니다. 그러나 도메인 모델이 복잡한 경우 EJB를 사용하지 않고 POJO(Plain Old Java Object)를 사용하는 것이 더 적합할 수 있습니다.EJB를 사용하지 않을 경우, 도메인 모델과 데이터 매퍼를 POJO로 구현하고, 필요 시 세션 빈을
Remote Facade(388)로 감쌀 수 있습니다. 이는 도메인 로직의 테스트와 실행을 EJB 컨테이너와 독립적으로 수행할 수 있게 합니다.테이블 모듈 패턴은 Java 환경에서 많이 사용되지 않지만, JDBC Row Set이 널리 사용되면서 점차 중요해질 가능성이 있습니다.
.NET:
.NET 환경에서는
Table Module(125)패턴이 지배적입니다. 이는 Microsoft의 Visual Studio와 그 역사에 기인한 것으로, 데이터 세트를 다루는 도구들이 이 패턴을 지원하기 때문입니다.도메인 모델을 사용할 수 있지만, .NET 환경에서는 더 복잡해지기 전까지
Table Module(125)을 사용하는 것이 효율적입니다. 이 패턴은 데이터 세트를 직접 다루는 기능이 뛰어나므로, 간단한 애플리케이션에는 적합합니다.웹 서비스와의 통합이 필요할 경우, 도메인 로직을 별도의 프로세스로 분리하지 않고 웹 서버에서 모두 실행하는 것이 효율적입니다.
기타 레이어링 스킴
이 글에서는 주로 세 가지 기본 레이어(프레젠테이션, 도메인, 데이터 소스)를 중심으로 설명하지만, 다른 레이어링 스킴도 존재합니다. 다른 접근 방식은 다음과 같습니다:
Brown 모델:
프레젠테이션, 컨트롤러/미디에이터, 도메인, 데이터 매핑, 데이터 소스의 다섯 레이어로 구성됩니다. 컨트롤러/미디에이터 레이어는 프레젠테이션과 도메인 레이어 사이의 중재자 역할을 하며, 데이터 매핑 레이어는 도메인과 데이터 소스 사이에서 중재자 역할을 합니다.
Core J2EE 패턴:
클라이언트, 프레젠테이션, 비즈니스, 통합, 리소스의 다섯 레이어로 구성됩니다. 여기서는 프레젠테이션 레이어를 클라이언트 측과 서버 측으로 분리하여 관리합니다.
Microsoft DNA:
프레젠테이션, 비즈니스, 데이터 접근의 세 레이어로 구성되며, 데이터 접근 레이어에서 생성된 레코드 셋이 비즈니스와 프레젠테이션 레이어 간의 데이터 전송 객체(DTO)로 사용됩니다.
Marinescu 모델:
프레젠테이션, 애플리케이션, 서비스, 도메인, 퍼시스턴스 레이어로 구성됩니다. 서비스 레이어는 워크플로우 로직을 관리하며, 도메인 로직과의 분리를 통해 유연성을 확보할 수 있습니다.
Nilsson 모델:
프레젠테이션, 애플리케이션, 도메인, 퍼시스턴스, 데이터 소스의 다섯 레이어로 구성되며, 저장 프로시저를 활용한 성능 최적화를 중시합니다.
이러한 다양한 레이어링 스킴은 특정 프로젝트의 요구사항에 따라 선택적으로 적용될 수 있으며, 필요에 따라 각 레이어를 추가하거나 생략할 수 있습니다.
Last updated