본문 바로가기

Dev.../소프트웨어 아키텍처

[SA강좌] Part 4-7 Domain Model 패턴 도메인 모델(Domain Model) 패턴 도메인 모델 패턴의 정의 도메인 모델 패턴은 행동과 데이터가 협력하는 도메인의 개체 모델 패턴이다. 그림 Ⅴ-10. 도메인 모델 패턴의 구조 도메인 모델 패턴의 설명 나쁜 비즈니스 로직은 매우 복잡하다. 비즈니스 규칙과 로직은 많은 다른 사례와 행동에 편향적인 설명을 한다. 도메인 모델 패턴은 내부적으로 연결된 개체들의 망을 생성한다. 주문 양식에 있는 협력체 만큼이나 크거나 단일 라인 만큼 작은 각 개체는 몇몇 의미있는 개체를 표현한다. 도메인 모델 패턴은 언제 사용하는가? 만일 도메인 모델 패턴 사용을 생각한다면, 데이터베이스와 상호작용을 위한 첫 번째 선택은 데이터 매핑 패턴이다. 이 패턴은 데이터베이스에서 도메인 모델 패턴이 독립되도록 유지하고, 도메인 .. 더보기
[SA강좌] Part 4-6 Transaction Script 패턴 트랜잭션 스크립트(Transaction Script) 패턴 트랜잭션 스크립트 패턴의 정의 개별 프로시저가 프리젠테이션 레이어에서 단일 요청을 관리할 때 비즈니스 로직을 프로시저로 사용하여 조직화하는 패턴이다. 그림 Ⅴ-9. 트랜잭션 스크립트 패턴의 구조 트랜잭션 스크립트 패턴의 설명 대부분의 어플리케이션은 트랜잭션의 연속으로 생각된다. 트랜잭션은 특별한 방법에 의해 조직된 정보를 보여주고, 다른 것으로 변화시킨다. 클라이언트와 서버 시스템 사이에 상호 작용은 비즈니스 로직의 많은 부분을 포함하고 있다. 몇몇 경우는 데이터베이스에 있는 정보를 화면에 보여주는 것 같이 단순 할 수 있다. 다른 경우는 다수의 검증과 계산의 단계들을 포함할 수 있다. 트랜잭션 스크립트는 단일 프로시저, 데이터베이스 직접 호출 .. 더보기
[SA강좌] Part 4-5 OR Mapping 패턴 개요 OR Mapping 패턴 개요 OR Mapping 패턴은 Data Source Architecture 패턴과 OR Mapping 행동 패턴, OR Mapping 구조 패턴, OR 메타데이터 매핑 패턴으로 분류된다. 그림 Ⅴ-4. OR 매핑 패턴 Datasource Architecture Pattern은 도메인 객체와 데이터베이스가 연결되는 방법을 결정한다. OR Mapping 행동 패턴은 데이터베이스에서 정보를 load하는 방식과 도메인 객체의 정보를 save하는 방식을 결정한다. OR Mapping 구조 패턴은 객체 모델에서 관계형 데이터베이스 모델로 변환하는 방식을 결정한다. OR 메타데이터 매핑 패턴은 OR 매핑에 대한 코드를 메타데이터를 사용하여 자동으로 생성하는 방법을 결정한다. Datasour.. 더보기
[SA강좌] Part 4-4 Business Logic Pattern 개요 Business Logic Pattern 개요 그림 Ⅴ-3. Business Logic Pattern Business logic의 설계 방식을 결정하기 위해서는 먼저 컨트롤러와 도메인 객체 사이의 관계를 정의해야 한다. 컨트롤러는 거의 모든 business logic을 가지고 있고 도메인 객체는 단순히 객체가 담고 있는 정보만을 제공하는 방법이 있다. 또 한가지 방법은 대부분의 로직을 도메인 객체에 넣고 컨트롤러는 객체를 호출만 하는 방식이다. 컨트롤러의 역할이 정의된 후에는 도메인 객체의 형태를 결정해야 한다. 도메인 객체는 Transaction Script를 사용하면 쉽고 단순하게 구현할 수 있다. 그러나 Transaction Script는 코드 중복이 많고 로직이 복잡한 경우는 바람직하지 않다. D.. 더보기
[SA강좌] Part 4-3 Presentation Pattern 개요 Presentation Logic Pattern 개요 그림 Ⅴ-2. Presentation logic pattern Presentation Logic pattern은 사용자의 이벤트를 Business Logic layer에 전달하는 방법을 결정한다. 기본적으로 Presentation Logic은 Model View Controller 패턴을 사용하여 Model과 View를 분리하는 것이 바람직하다. Model View Controller 패턴을 사용하기로 결정했으면 page 웹 화면의 이벤트를 각 page별로 처리할 것인지 별도의 객체에서 처리할 것인지를 결정한다. 이 경우 page controller나 front controller를 사용한다. 화면이 복잡한 경우는 HTML에 embedded marke.. 더보기
[SA강좌] Part 4-2 설계 패턴의 개요 설계 패턴 이 장에서는 J2EE에 한정하여 설계 패턴을 제시한다. 개요 그림 Ⅴ-1. 설계 패턴 본 장에서 설명할 설계 패턴을 보여준다. Layer는 크게 Presentation Layer, Business Logic Layer, Datasource Layer로 나뉜다. Presentation Layer는 화면을 담당하는 layer이고 business logic layer는 업무 로직을 구현하는 layer이다. Datasource layer는 데이터를 저장하는 layer로 대부분의 시스템에서는 이 layer에서 데이터베이스와의 연결을 담당한다. Presentation layer에서 나타나는 패턴은 사용자가 화면에서 발생시킨 이벤트를 business logic layer에 전달하는 방식을 결정한다. Bus.. 더보기
[SA강좌] Part 4-1 아키텍처에서 개발로의 이행 아키텍처에서 개발로의 이행 이 장에서는 아키텍처에서 상세 설계, 구현으로 이행하기 위한 여러 가지 기법들을 소개한다. 아키텍처에서 상세 설계로 이행하기 위해서는 설계 패턴이 필요하고 상세 설계로 이행하기 위해서는 상세 설계 산출물에 대한 정의가 필요하다. 설계 패턴 중에서는 OR 매핑을 중점적으로 설명할 것이고 상세 설계 산출물에서는 UML notation에 추가되는 스테레오 타입에 대하여 설명하겠다. 이 Part4의 부분들은... 향후 지속적으로 업데이트를 하면서... 패턴의 다양한 부분들을 모두 기술해 볼 수 있었으면 좋겠다. ~.~ 특히나.. UI관련된 부분의 UI 관련 패턴은 도전하고픈 분야이기도 하다. ~.~ 더보기
[SA강좌] Part 3 연재완료... http://zetlos.tistory.com/entry/SA강좌-Part-3-1-소프트웨어-아키텍처-설계http://zetlos.tistory.com/entry/SA강좌-3-2-시스템-컨텍스트-정의 http://zetlos.tistory.com/entry/SA강좌-3-3-Component-Connector-View정의http://zetlos.tistory.com/entry/SA강좌-Part-3-4-Module-View-정의 http://zetlos.tistory.com/entry/SA강좌-Part-3-5-Allocation-View-정의 http://zetlos.tistory.com/entry/SA강좌-Part-3-6-Code-View-정의 http://zetlos.tistory.com/entry/SA.. 더보기
[SA강좌] Part 3-13 아키텍트의 의사 결정 항목 아키텍트의 의사 결정 항목 아키텍처가 결정해야 할 항목을 정의한다. J2EE에 대한 의사 결정 항목 그림 Ⅲ-41. JE22에 대한 의사결정 항목 성능에 대한 의사 결정 항목 Resource Demand Increase Computation Efficiency Reduce Computational Overhead Maintain Event Rate Control Frequency of Sampling Resource Management Introduce Concurrency Maintain Multiple Copies Increate Available Copies Resource Arbitration Scheduling Policy 가용성에 대한 의사 결정 항목 결함 검출 Ping/echo Heartbe.. 더보기
[SA강좌] Part 3-12 소프트웨어 아키텍처 설계 산출물 관계 소프트웨어 아키텍처 설계 산출물 관계 소프트웨어 아키텍처 설계 및 구현 산출물은 크게 두 개의 주요 카테고리로 구분할 수 있다. 이 두 개의 주요 카테고리는 요구사항 정의와 소프트웨어 아키텍처로 나뉜다. 요구사항 정의는 기능적 요구사항과 품질적 요구사항으로 나눌 수 있다. 요구사항 정의의 요구사항들을 살펴보면, 기능적 요구사항은 세가지(required, preferred, optional)의 우선순위로 분류가 된다. 품질적 요구사항은 시나리오 이력(profile)로 기술된다. 여기서 소프트웨어 아키텍처는 네 가지의 산출물로 구성된다. 소프트웨어 아키텍처는 시스템 컨텍스트, 아키텍처스타일, 아키텍처 스트럭처와 설계 의사결정으로 구성된다. 먼저 시스템 컨텍스트는 소프트웨어 시스템의 인터페이스가 컨텍스트로 정.. 더보기