꿈꾸는자의 생각의 파편들... :: 'SA' 태그의 글 목록 (3 Page)

달력

10

« 2018/10 »

  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  •  
  •  
  •  

서비스 레이어(Service Layer) 패턴

서비스 레이어 패턴의 정의

가능한 오퍼레이션의 집합을 만들고, 각 오퍼레이션에 있는 어플리케이션의 응답에 대응하는 서비스 레이어를 사용하여 어플리케이션의 경계를 정의하는 패턴이다.

그림 -12. 서비스 레이어 패턴의 구조

서비스 레이어 패턴의 설명

엔터프라이즈 어플리케이션은 전형적으로 데이터 저장과 로직 구현을 위한 다른 종류의 인터페이스를 요구한다. 인터페이스의 예는 데이터 로더, 사용자 인터페이스, 게이트웨이 통합 등등이다. 이들 인터페이스는 다른 목적을 가지고 있음에도 불구하고, 이들 인터페이스들은 자주 어플리케이션과의 상호작용을 필요하다.

서비스 레이어는 어플리케이션의 경계를 정의하고, 클라이언트 레이어와 인터페이스를 인식하는 이용 가능한 오퍼레인션들의 집합이다. 서비스 레이어는 어플리케이션의 비즈니스 로직, 프리젠테이션의 처리, 레이어의 오퍼레이션에 있는 응답 조정을 캡슐화한다.

  • 도메인 모델의 상위에 있는 추상화된 레이어
  • 어플리케이션은 도메인 모델에 직접 접근 대신에 단지 서비스 레이어를 사용
  • 예제 : 세션빈즈

장점

  • 도메인 모델 위에서 트랜잭션 스크립트와 같은 함수
  • 다양한 도메인 개체들을 연결함( : 아답트 클래스)
  • 다양한 도메인 개체들에서 공용 CRUD 코드를 공유
  • 원격 호출을 위해 설계됨

단점

  • 도메인 모델위에 레이어 추가가 복잡함
  • 서비스 구현 확장 – CRUD 부분에서 서비스 레이어 있는 함수 호출을 필요로

서비스 레이어 패턴은 언제 사용하는가?

서비스 레이어의 이점은 많은 종류의 클라이언트에서 이용이 가능한 어플리케이션의 오퍼레이션 공통 집합을 정의하고, 각 오퍼레이션을 어플리케이션 응답에 대응한다. 이러한 응답은 다중 트랜잭션의 자원들에 거처서 자동적으로 처리하는데 필요한 어플리케이션의 로직을 포함한다.

서비스 레이어 패턴의 예제:세금 인식

인식서비스 클래스의 메소드들은 오퍼레이션들의 어플리케이션 로직을 기술하고, 도메인 개체 클래스들을 대표한다. 아래는 도메인 로직을 위한 도메인 모델 패턴에서의 예제이다.

 

publuc class ApplicationService {

protected EmailGateway getEmailGateway() {

// return an intance of EmailGateway

}

proteceted IntegrationGateway getIntegrationGateway() {

// return an instance of IntegrationGateway

}

}

public interface EmailGateway {

void sendEmailMessage(String toAddress, String subject, String body);

}

public interface IntegrationGateway {

void publishRevenueRecogitionCalculation(Contract contract);

}

public class RecognitionService extends ApplicationService {

public void caculateRevenueRecognitions(long contractName) {

Contract contract = Contract.readForUpdate(contractNumber);

contract.caluateRecognitions();

getEmailGateway().sendEmailMessage(

contract.getAministrationEmailAddress(),

"RE:Contract #" + contractNumber,

contract + "has had revenue recognitions calculated.");

getIntegrationGateway().publishReveneueRecognition(contract);

}

public Money recognizedRevenue(long contractNumber, Date asOf) {

return Contract.read(contractNumber).recognizedRevenue(asOf);

}

}

Posted by 꿈꾸는자의 생각의파편들

테이블 모듈(Table Module) 패턴

테이블 모듈 패턴의 정의

데이터베이스 테이블 또는 뷰에 있는 모든 행에 대한 비즈니스 로직을 다루기 위한 단일 인스턴스 패턴이다.

그림 -11. 테이블 모듈 패턴의 구조

테이블 모듈 패턴의 설명

테이블 모듈 패턴은 데이터베이스에 있는 테이블 마다 하나의 클래스에 대응하는 도메인 로직을 구성한다. 또한, 클래스의 단일 인스턴스는 데이터에 행동 할 수 있는 다양한 프로시저를 포한한다. 도메인 모듈 패턴과 비교되는 주요한 구분은 만일 많은 주문에 대한 처리를 원하는 경우 도메인 모듈 패턴은 주문 마다 하나의 주문 개체를 가지게 된다. 반면, 테이블 모듈 패턴은 모든 주문을 처리하기 위해 하나의 개체만을 가진다.

언제 이 패턴을 사용하는가?

테이블 모듈 패턴은 매우 테이블 지향 데이터에 기반한다. 그러므로, 레코드 집합 패턴을 사용하는 데이터 집합의 접근을 할 때 유용하다.

그러나, 테이블 모듈 패턴은 복잡한 로직을 구조화하는 개체들의 모든 능력을 제공하지는 않는다. 인스턴스 대 인스턴스 관계를 직접적으로 가지 않고, 다향성은 잘 작업되지 않는다. 이러한 이유로 복잡한 도메인 로직을 처리하기 위해서는 도메인 모델 패턴이 더 좋은 선택이 된다.

만일 도메인 모델 패턴에 있는 개체와 데이터베이스 테이블이 관계적으로 유사하면, 활동 레코드 패턴을 사용하는 도메인 모델 패턴을 사용하는 것이 좋다. 테이블 모듈 패턴은 도메인 모델 패턴과 활동 레코드 패턴을 사용하는 도메인 모델 패턴 보다 더 잘 작업한다.

Posted by 꿈꾸는자의 생각의파편들

도메인 모델(Domain Model) 패턴

도메인 모델 패턴의 정의

도메인 모델 패턴은 행동과 데이터가 협력하는 도메인의 개체 모델 패턴이다.

그림 -10. 도메인 모델 패턴의 구조

도메인 모델 패턴의 설명

나쁜 비즈니스 로직은 매우 복잡하다. 비즈니스 규칙과 로직은 많은 다른 사례와 행동에 편향적인 설명을 한다. 도메인 모델 패턴은 내부적으로 연결된 개체들의 망을 생성한다. 주문 양식에 있는 협력체 만큼이나 크거나 단일 라인 만큼 작은 각 개체는 몇몇 의미있는 개체를 표현한다.

도메인 모델 패턴은 언제 사용하는가?

만일 도메인 모델 패턴 사용을 생각한다면, 데이터베이스와 상호작용을 위한 첫 번째 선택은 데이터 매핑 패턴이다. 이 패턴은 데이터베이스에서 도메인 모델 패턴이 독립되도록 유지하고, 도메인 모델과 데이터베이스 스키마 차이가 발생하는 사례를 조작하기 위한 접근을 제공한다.

도메인 모델을 사용할 때, 서비스 레이어 패턴을 고려해야 한다. 이 패턴은 도메인 모델 패턴이 API에서 멀어지도록 한다.

도메인 모델 패턴의 적용 예제 : 세금 계산

직접적인 인식은 예제가 가지고 있는 행동과 데이터의 모든 클래스를 인식하는 것이다. 만일 개체의 값이 임의 데이트를 인식하면, 세금 인식 클래스는 검색을 위한 간단한 메서드를 아래와 같이 포함하게 된다.

class RevenueRecognition ...

private Money amount;

private MfDate date;

public RevenueRecognition(Money amount, MfDate date) {

this.amount = amount;

this.date = date;

}

public Money getAmount() {

return amount;

}

boolean isRecognizable(MfDate asOf) {

return asOf.after(date) || asOf.equals(date);

}

얼마나 많은 세금이 특정 일자에 인식 되었는지를 계산하는 것은 계약과 세금 인식 클래스를 포함한다.

class Contract ...

 

private List revenueRecognitions = new ArrayList();

public Money recognizedRevenue(MfDate asOf) {

Money result = Money.dollars(0);

Iterator it = revenueRecognitions.iterator();

while (it.hasNext()) {

RevenueRecognition r = (RevenueRecognition) it.next();

if (r.isRecognizableby(asOf))

result = result.getAmount();

}

return result;

}

도메인 모델에서 공통점을 찾기는 것은 얼마나 간단한 작업들이 다중 클래스들과 상호작용을 하는지를 인식하는 것이다.

class Contract ...

 

private Product product;

private Money revenue;

private MfDate whenSigned;

private Long id;

public Contract(Product product, Money revenue, MfDate whenSigned) {

this.product = product;

this.revenue = revenue;

this.whenSigned = whensinged;

}

 

class Product ...

 

private String name;

private RecognitionStrategy recognitionStrategy;

public Product(String name, RecognitionStrategy recognitionStrategy) {

this.name = name;

this.recognitionStrategy = recognitionStrategy;

}

public static Product newWordProcessor(String name) [

return new Product(name, new CompleteRecognitionStrategy());

}

public static Product newSpreadsheet(String name) {

return new Product(name, new TreeWayRecognitionStrategy(60,90));

}

public static Product newDatabase(String name) {

return new Product(name, new TreeWayRecognitionStrategy(30,60));

}

 

class RecognitionStrategy ...

 

abstract void calculateRevenueRecognitions(Contract contract);

 

class CompleteRecognitionStrategy ...

 

void calculateRevenueRecognitions(Contract contract) {

contract.addRevenueRecognitions(new RevenueRecognition(contract.getRevenue(),

contract.getWhenSigned());

}

 

class TreeWayRecognitionStrategy ...

 

 

private int firstRecognitionOffset;

private int secondRecognitionOffset;

public ThreeWayRecognitionStrategy(int firstRecognitionOffset,

int secondRecognitionOffset)

{

this.firstRecognitionOffset = firstRecognitionOffset;

this.secondRecognitionOffset = seondRecognitionOffset;

}

void calculateRevenueRecognitions(Contract contract) {

Money[] allocation = contract.getRevnue().allocate(3);

contract.addRevenueRecognition(new RevenueRecognition

(allocation[0], contract.getWhenSigned());

contract.addRevenueRecognition(new RevenueRecognition

(allocation[1], contract.getWhenSigned().addDays(firstRecognitionOffset)));

contract.addRevenueRecognition(new RevenueRecognition

(allocation[2], contract.getWhenSigned().addDays(firstRecognitionOffset)));

}

 

class Tester ...

 

private Product word = Product.newWordProcessor("Thinking Word");

private Product calc = Product.newSpreadsheet("Thinking Calc");

private Product db = Product.newDatabase("Thinking DB");

일단 모든 것이 설정되면, 세금 인식 계산은 전략 서브클래스의 임의 지식을 요청한다.

 

class Contract ...

 

public void calculateRecognitions() {

product.calculateRevenueRecognition(this);

}

 

class Product ...

 

void calculateRevenueRecognition(Contract contract) {

recognitionStrategy.calculateRevenueRecognition(contract);

}

Posted by 꿈꾸는자의 생각의파편들

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

트랜잭션 스크립트 패턴의 정의

개별 프로시저가 프리젠테이션 레이어에서 단일 요청을 관리할 때 비즈니스 로직을 프로시저로 사용하여 조직화하는 패턴이다.

그림 -9. 트랜잭션 스크립트 패턴의 구조

트랜잭션 스크립트 패턴의 설명

대부분의 어플리케이션은 트랜잭션의 연속으로 생각된다. 트랜잭션은 특별한 방법에 의해 조직된 정보를 보여주고, 다른 것으로 변화시킨다. 클라이언트와 서버 시스템 사이에 상호 작용은 비즈니스 로직의 많은 부분을 포함하고 있다. 몇몇 경우는 데이터베이스에 있는 정보를 화면에 보여주는 것 같이 단순 할 수 있다. 다른 경우는 다수의 검증과 계산의 단계들을 포함할 수 있다.

트랜잭션 스크립트는 단일 프로시저, 데이터베이스 직접 호출 또는 씬 데이터베이스 레퍼와 비슷하게 모든 비즈니스 로직을 조직화한다. 각 트랜잭션은 자신의 트랜잭션 스크립트를 갖는다. 뿐만 아니라 공통 서브 작업들은 서브프로시저로 나누어 진다.

트랜잭션 스크립트 패턴은 언제 사용하는가?

트랜잭션 스크립트의 장점은 단순성에 있다. 이러한 방법으로 로직을 구조화하는 것은 단지 로직의 작은 단위를 가지는 어플리케이션을 위해 자연스러운 것 이다. 그리고, 이 것은 수행과 이해에서 매우 적은 과부하를 포함한다.

비즈니스 로직은 점점 더 복잡해지고 있다. 그러나, 비즈니스 로직을 잘 설계된 상태로 유지하는 것은 어렵다. 하나 특별한 문제점은 트랜잭션들 사이의 중첩성 이다.

주의 깊은 분해는 많은 이러한 문제점들을 완화해준다. 그러나, 더욱 복잡한 비즈니스 도메인은 도메인 모델 패턴의 작성을 필요로 한다. 도메인 모델 패턴은 코드를 구조화하데 더 많은 선택을 주고, 가독성을 증가하고, 중복성을 감속한다.

트랜잭션 스크립트 패턴의 적용 예제 : 세금 계산

이 예제는 두 가지 트랜잭션 스크립트를 사용한다. 하나는 계약을 위해 세금을 계산하는 것이고, 다른 하나는 계약에서 특정 일자에 의해 계산된 세금 금액을 알려주는 것이다. 데이터베이스는 세 가지의 테이블을 가지고 있다. 제품을 위한 테이블, 계약을 위한 테이블, 그리고 세금 인식을 위한 테이블이다.

 

CREATE TABLE products(ID int primary key, name varchar, type varchar)

CREATE TABLE contracts(ID int primary key, product int, revenue decimal, dateString date)

CREATE TABLE revenueRecognitions(contract int, amount decimal, recognizedOn Date,

PRIMARY KEY (contract, recognizedOn))

 

첫 번째 트랜잭션 스크립트는 특정 일자의 세금의 합계를 계산하는 것이다. 계산을 위해 두 단계를 거치게 된다. 세금 인식 테이블에서 적절한 행을 선택한다. 그리고, 합계를 구한다.

많은 트랜잭션 스크립트 설계들은 데이터베이스에 직접적으로 조작을 위한 스크립트를 가지고 있다. 예를 들어서 프로시저에 SQL 코드를 넣는 것이다. 테이블 데이터 게이트웨이 패턴은 SQL 질의어를 포함하고 있는 간단한 예이다. 이 예제는 매우 간단하다. 각 테이블을 위해 하나 이상의 단일 게이트웨이를 사용한다. 아래의 예제는 게이트웨이에서 검색 메서드를 정의하고 있다.

 

class GateWay ...

 

private static final String findRecognitionsStatement =

"SELECT amount " +

" FROM revenueRecognitions " +

" WHERE contract = ? AND recognizedOn <= ? ";

private Connection db;

 

public ResultSet findRecognitionsFor(long contractID, MfDate asof) throws SQLException {

PreparedStatement stmt = db.preparedStatement(findRecognitionsStatement);

stmt = db.preparedStatment(findRecognitionsStatement);

stmt.setLong(1, contractID);

stmt.setDate(2, asof.toSqlDate());

ResultSet result = stmt.executeQuery();

return result;

}

 

게이트웨이에서 결과 집합으로 전달된 것을 근간으로 합계를 구하는 스크립트는 다음과 같다.

 

class RegonitionService ...

 

public Money recognizedRevenue(long contractNumber, mfDate asOf) {

Money result = Money.dollars(0);

try {

Result rs = db.findRecognitionsFor(contractNumber, asOf);

while(rs.next()) {

result = result.add(Money.dollars(rs.getBigDecimal("amount")));

}

return result;

} catch(SQLException e) {throw new ApplicationException(e);

}

}

 

이와 같이 간단히 계산을 하는 경우 메모리 상의 스크립트는 금액을 합하는 집합 함수를 사용하는 SQL문 호출로 대치될 수 있다. 존재하는 계약 테이블에서 세금 인식을 계산하기 위해서, 아래와 같이 코드를 나누었다. 서비스의 스크립트는 비즈니스 로직을 수행한다.

 

class RegonitionService ...

 

public void calculateRevenueRecognitions(long contractNumber) {

try {

ResultSet contracts = db.findContract(contractName);

contracts.next();

Money totalRevenue = Money.dollars(contracts.getBigDecimal("revenue");

MfDate recognitionDate = new MfDate(contracts.getDate("dateSigned"));

String type = contracts.getString("type");

if(type.equls("S")) {

Money[] allocation = totalRevenue.allocate(3);

db.insertRecognition(contractNumber, allocation[0], recognitionDate);

    db.insertRecognition(contractNumber, allocation[1], recognitionDate.addDate(60));

    db.insertRecognition(contractNumber, allocation[2], recognitionDate.addDate(90));

} else if (type.equals("W")) {

db.insertRecognition(contractNumber, totalRevenue, recognitionDate);

} else if (type.equals("D")) {

Money[] allocation = totalRevenue.allocate(3);

db.insertRecognition(contractNumber, allocation[0], recognitionDate);

    db.insertRecognition(contractNumber, allocation[1], recognitionDate.addDate(30));

    db.insertRecognition(contractNumber, allocation[2], recognitionDate.addDate(60));

}

} catch(SQLException e) { throw new ApplicationException(e));

}

}

 

Money 패턴을 사용하여 세금 수집을 수행헀다는 것에 주목하자. 테이블 데이터 게이트웨이 패턴은 SQL 지원을 제공한다. 계약 테이블 검색을 위한 코드는 아래와 같다.

 

class GateWay ...

 

private static final String findContractStatement =

" SELECT " +

" FROM contract c, product p " +

0]

]

ttutri " WHERE ID = ? AND c.product = p.ID ";

 

public ResultSet findContract(long contractID) throws SQLException {

PreparedStatement stmt = db.preparedStatement(findContractStatement);

stmt.setLong(1, contractID);

ResultSet result = stmt.executeQuery();

return result;

}

 

두 번째로 입력을 위해서 코드를 추가하는 것은 아래와 같다.

 

class GateWay ...

 

public void insertRecognition(long contractID, Money amount, MfDate asof) throws SQLException {

PreparedStatement stmt = db.preparedStatement(insertRecognitionStatment);

stmt.setLong(1, contractID);

stmt.setBigDate(2, amount);

stmt.setDate(3, asof.toSqlDate());

stmt.executeUpdate();

}

private static final String insertRecognitionStatement =

"- INSERT INTO revenueRecognitions VALUE(?, ?, ?)";

 

자바 시스템에서 인식 서비스는 일반 클래스 또는 세션 빈이 될 수 있다. 도메인 모델 패턴의 예제와 비교를 하면, 위의 예제가 매우 간단하다는 것을 할 수 있다.

Posted by 꿈꾸는자의 생각의파편들

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 매핑에 대한 코드를 메타데이터를 사용하여 자동으로 생성하는 방법을 결정한다.

Datasource Architecture Pattern은 Table Data Gateway, Row Data Gateway, Active Record, Data Mapper로 나누어진다.

그림 -5. Datasource Architecture Pattern

Table Data Gateway는 한 인스턴스가 테이블과 연결된다. Row data gateway는 한 레코드가 인스턴스와 연결된다. 도메인 로직 객체가 테이블 매핑 로직도 가지고 있는 경우에는 Active Record를 쓴다. 별도의 OR Mapping Layer를 만들거나 OR Mapping 툴을 사용하는 경우에는 Data Mapper를 사용한다.

OR Mapping 행동 패턴은 Unit of Work와 Identity Map, Lazy Load 등이 있다.

그림 -6. OR Mapping 행동 패턴

Identity Map은 객체가 오직 한번만 메모리에 load되도록 한다. Unit of Work는 트랜잭션에 의해 영향을 받는 모든 객체의 리스트를 관리한다. Lazy Load는 Master-detail 성격의 데이터에 대해 Master만 가져오고 추후 detail 데이터가 필요한 경우 메모리에 load할 때 사용한다.

OR Mapping 구조 패턴은 Identity Field, Foreign Key Mapping, Association Table Mapping, Dependent Maping, Embedded Value, Serialized LOB, Single Table Inheritance, Class Table Inheritance, Concrete Table Inheritance, Inheritance Mapper등이 있다.

그림 -7. OR Mapping 구조 패턴

Foreign Key Mapping은 객체 사이의 참조를 테이블의 foreign key에 매핑한다. Identity Field는 key를 사용하여 객체와 매핑되는 테이블을 찾는다. Embedded Value는 객체의 몇 개의 field를 embedded 객체를 사용하여 표현한다. Association Table Mapping은 Association을 테이블에 매핑한다. Depedent Mapping은 collection을 가져오는 로직을 별도의 객체로 처리할 경우 사용한다.

복합 객체를 저장하는 경우는 Serialized LOB를 사용한다.

상속 관계는 concrete table inheritance, class table inheritance, inheritance mapper, single table inheritance를 사용하여 구현한다.

OR 메타테이터 매핑 패턴은 Metadata Mapping, Query Object, Repository로 나누어 진다.

그림 -8. OR 메타데이터 매핑 패턴

인터프리터 방식으로 실행 중에 쿼리를 생성하여 실행할 경우는 query object를 사용한다. 메타 데이터를 사용하여 OR mapping 코드를 생성하는 경우는 metadata mapping을 사용한다. 사용자의 action에 매핑되는 쿼리를 찾아서 실행하는 경우에는 repository를 사용한다.

Posted by 꿈꾸는자의 생각의파편들

Business Logic Pattern 개요

그림 -3. Business Logic Pattern

Business logic의 설계 방식을 결정하기 위해서는 먼저 컨트롤러와 도메인 객체 사이의 관계를 정의해야 한다. 컨트롤러는 거의 모든 business logic을 가지고 있고 도메인 객체는 단순히 객체가 담고 있는 정보만을 제공하는 방법이 있다. 또 한가지 방법은 대부분의 로직을 도메인 객체에 넣고 컨트롤러는 객체를 호출만 하는 방식이다.

컨트롤러의 역할이 정의된 후에는 도메인 객체의 형태를 결정해야 한다. 도메인 객체는 Transaction Script를 사용하면 쉽고 단순하게 구현할 수 있다. 그러나 Transaction Script는 코드 중복이 많고 로직이 복잡한 경우는 바람직하지 않다. Domain Model는 완전한 객체지향 방식을 적용하는 방법으로 객체지향 개념에 익숙하지 않은 경우에는 사용하기가 쉽지 않다. Table Module은 한 테이블당 객체 하나를 사용하는 방식으로 Transaction Script와 Domain Model의 장점을 조합한다.

Posted by 꿈꾸는자의 생각의파편들

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 marker를 넣어서 사용해야 하며 이 경우 JSP나 ASP에서 다양한 기능을 제공한다. 이 패턴은 template view라고 불린다. 도메인 정보를 읽어서 화면으로 단순하게 변환하는 경우는 Transform View와 Two Step View를 사용한다.

Posted by 꿈꾸는자의 생각의파편들

설계 패턴

이 장에서는 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에 전달하는 방식을 결정한다.

Business Logic layer의 패턴은 business logic을 구현하는 방법을 결정한다. 여기에서는 프로시저 방식으로 구현하는 방법, 객체지향으로 구현하는 방법, 객체지향과 프로시저 방식의 장점만으로 모아서 구현하는 방법이 있다.

Datasource layer에서 나타나는 패턴은 크게 두 가지로 나뉜다. OR Mapping은 Business Logic layer를 관계형 데이터베이스와 연결하는 방법을 결정한다. Enterprise Integration Pattern은 관계형 데이터베이스를 제외한 외부 시스템을 연결하는 방법을 결정한다.

Session States는 웹 서버, 어플리케이션 서버, 데이터베이스 서버에서 사용자의 session을 관리하는 방법을 결정한다.

분산 전략은 어플리케이션 서버를 사용할 경우에 나타나는 패턴이다. 동시에 여러 사용자가 시스템에 접근할 때 동시성을 관리하는 방법을 제시한다.

기타 패턴은 시스템 구현에서 사용할 수 있는 다양한 패턴들과 GangofFour에서 제시한 설계패턴을 소개한다.

Posted by 꿈꾸는자의 생각의파편들

 

아키텍처에서 개발로의 이행

이 장에서는 아키텍처에서 상세 설계, 구현으로 이행하기 위한 여러 가지 기법들을 소개한다. 아키텍처에서 상세 설계로 이행하기 위해서는 설계 패턴이 필요하고 상세 설계로 이행하기 위해서는 상세 설계 산출물에 대한 정의가 필요하다. 설계 패턴 중에서는 OR 매핑을 중점적으로 설명할 것이고 상세 설계 산출물에서는 UML notation에 추가되는 스테레오 타입에 대하여 설명하겠다.

이 Part4의 부분들은... 향후 지속적으로 업데이트를 하면서... 패턴의 다양한 부분들을 모두 기술해 볼 수 있었으면 좋겠다. ~.~

특히나.. UI관련된 부분의 UI 관련 패턴은 도전하고픈 분야이기도 하다. ~.~

Posted by 꿈꾸는자의 생각의파편들

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강좌-Part-3-7-소프트웨어-아키텍처-평가
[SA강좌] Part 3-8 소프트웨어 아키텍처 상세화
[SA강좌] Part 3-9 아키텍처스타일 적용
[SA강좌] Part 3-10 아키텍처, 설계 패턴 적용
[SA강좌] Part 3-11 품질 요구사항 구조적 그룹핑 
[SA강좌] Part 3-12 소프트웨어 아키텍처 설계 산출물 관계
[SA강좌] Part 3-13 아키텍트의 의사 결정 항목


SA강좌 Part 4 연재 조만간 들어갑니다.

~.~

Posted by 꿈꾸는자의 생각의파편들