마틴 파울러 PoEAA(패턴 오브 엔터프라이즈 어플리케이션 아키텍처) 요약.

마틴 파울러의 PoEAA는 엔터프라이즈 어플리케이션의 아키텍처가 어떻게 구성되는 것인가에 대한 최고의 책입니다. 도입부의 [도메인 로직을 구성하는 패턴]은 조금은 어렵게 느껴지는 내용입니다. 전체적인 내용을 파악한 후 몇번에 걸쳐 정독 하는 것이 이 책의 내용을 이해하는 데 도움이 될 것입니다.

아래는 PoEAA 의 전체적인 요약 포스트의 번역 입니다.

엔터프라이즈 하면 역시 스타트랙.PoEAA




원문주소 : http://moshfegh.spaces.live.com/blog/cns!40F968A11C62F49A!192.entry

제목 : Summary notes from Martin Fowler's PoEAA

도메인 로직을 구성하는 패턴
1. 트랜잭션 스크립트 (Transaction Script) : 프로시저럴, 많은 중복, 모든 개발자가 이해하기 쉽고 간단합니다.
2. 테이블 모듈 (Table Module) : .NET 에서의 DataSet 처럼 트랜잭션 스크립트와 도메인 모델 사이의 중간이며, 도메인 로직을 핸들링하기가 트랜잭션 스크립트 보다 쉽습니다.
3. 도메인 모델 (Domain Model) : 복잡한 비즈니스 로직을 가지는 프로젝트에 적당합니다. 코드 중복 문제를 해결합니다.


데이터 소스로 부터 간단한 입출력만을 하는 프로젝트의 경우에는 트랜잭션 스크립트가 적합 할수 있으며, 복잡한 비즈니스 로직을 처리해야 한다면 도메인 모델이 적합합니다.


아이덴티티 맵 (Identity Map)

이름 그대로 오브젝트들을 구분할수 있는 Map, 오브젝트에 아이디를 부여 하여 메모리에 로딩 하여 맵으로 가지고 있는 형태. Look Up 하여 오브젝트를 참조할 수 있도록 지원.
메모리에 로드된 오브젝트는 상태가 변경될 수 있는데, 그 변경된 상태에 대해서도 다른 오브젝트에서 접근 가능해야 한다. 아이덴티티 맵은 세션 스코프를 가지며, 각각의 세션 내에서 인스턴스는 격리됨을 보장 받아야 합니다.
Unit of Work를  사용한다면 아이덴티티 맵이 위치할 수 있는 최적의 장소이며, Unit of work를 사용하지 않는 다면 세션에 결합된 Registry 가 적절한 장소입니다.

아이덴티티 맵의 다른 가치는 데이터베이스에 대한 캐쉬 역할을 하는 것입니다.


게이트웨이 (Gateway)
외부 시스템 또는 자원에 대한 접근을 캡슐화 하는 오브젝트. API와 같은 외부 자원을 취급하는데 좋습니다. API 코드들을 감쌈으로써 일반적인 클래스의 인터페이스로 보이게 할 수 있습니다.

 

분리된 인터페이스 (Separated Interface)
구현으로부터 분리된 인터페이스를 정의 합니다. 인터페이스 정의는 어떤 패키지에서 사용하고, 다른 패키지에서는 구현을 합니다. 이러한 구현은 클라이언트의 인터페이스에 대한 의존을 구현으로 부터 완벽히 분리할 수 있습니다.

분리된 인터페이스의 구현은 팩토리 오브젝트(Factory Object)를 이용하여 로드할 수 있습니다. 컨파일-타임(compile-time) 의존을 제거 하기 위해서 팩토리는 리플렉션(Reflection)을 이용하여 런-타임(run-time)에 구현을 로드할 수 있습니다.


이 패턴은 두 부분으로 구성되는 시스템에서 의존을 제거하기 위해서 필요하다. 예를 들어 도메인 코드가 데이터 매퍼(Data Mapper)를 호출하는 것 처럼 한 레이어에서 다른 레이어의 코드를 호출할 때 필요합니다.


레지스트리 (Registry)
오브젝트 또는 서비스를 다른 오브젝트들이 사용할 수 있도록 잘 알려진 공용 오브젝트.


특수 케이스 (Special Case)
특수한 경우에 특별한 행위를 제공하는 클래스. 일반 어플리케이션에서 null 값을 검사하는 패턴 등에서 이용할 수 있습니다. 다수의 경우에 매우 많은 곳에서 null 값을 검사할 필요가 있다면 이 패턴을 이용할 수 있습니다.
null 값을 반환하는 대신에 호출자가 기대하는 특별한 오브젝트를 반환할 수 있다. 단, 반환되는 오브젝트는 해로운 행위를 하지 않아야 합니다.


플러그인 (Plugin)
컴파일시가 아닌 설정(Configuration)에서 클래스를 연결 하는 것. 런타임 환경에서 다른 행위가 요구되어 질때 이 패턴을 사용 할 수 있다. 설정은(Configuration)은 리빌드 또는 재배포를 요구하지 않아야 합니다.


레이어링 (Layering)
관계 데이터를 단순히 보여주고, 입출력을 수행하는 프로젝트에서는 레이어링을 적용할 필요가 없습니다. 문제는 도메인 로직(비즈니스 규칙, 유효성 검사, 연산을 수행하는)에서 발생합니다. 클라이언트 UI에 포함된 비즈니스 코드들은 도메인이 복잡해 감에 따라 함께 일하기가 매우 어려워지고, 중복된 코드들을 양산합니다. 이 말은 작은 변경에도 수많은 화면이 문제를 일으킬수 있음을 의미합니다.

대안으로은 비즈니스 로직은 저장프로시저(Stored Procedure) 에 집어 넣는 것입니다. 저장프로시저는 서투른 코드를 유발하는 제한된 구조화된 메커니즘을 제공합니다.

교과서적인 3-Layer는 프리젠테이션, 도메인, 데이터소스 입니다.

 

레이어드 디자인

웹 어플리케이션에서의 레이어드 디자인과 Cross-Cutting Concern.


 


신고

이 글을 Twitter / Facebook 에 공유하기
이 글이 유익하다면 아래의 트위터 버튼을 눌러 공유해 주시거나, 페이스북 "좋아요" 버튼을 눌러 주세요.

   


Posted by 반더빌트


티스토리 툴바