논리 모델: 애플리케이션 정의 및 계획
COM+ 애플리케이션 디자인 프로세스의 두 번째 단계는 개념적 모델을 프레젠테이션 계층 또는 사용자 서비스인 3계층 아키텍처의 논리적 계층으로 분할하는 것입니다. 중간 계층 또는 비즈니스 서비스 및 데이터 계층 또는 데이터 서비스. 3계층 아키텍처에 익숙하지 않은 경우 Three-Tier 아키텍처 모델 사용을 참조하세요.
명사와 동사에 대한 개념적 모델을 확인하여 이 프로세스를 시작합니다. 명사는 종종 비즈니스 개체(클래스)로 변환될 수 있으며, 명사와 연결된 동사는 작업(클래스의 메서드)으로 변환될 수 있습니다. 모든 명사 를 비즈니스 개체로 정의하기는 어려울 수 있지만 논리적 모델을 완료할 때 누락 또는 실수가 분명해집니다.
대부분의 비즈니스 개체는 비즈니스 서비스 계층에 있으며 나머지 개체는 사용자 서비스 계층의 사용자 인터페이스 개체와 데이터 서비스 계층의 데이터 개체로 나뉩니다. 3계층 아키텍처를 사용하여 논리 모델을 만들 때 다음 사항에 유의하세요.
- 개념적 디자인의 명사 중 일부는 실제 데이터 조각을 나타내지 않지만 시스템에 대한 작업 또는 시스템에서 비즈니스 개체의 역할을 나타낼 수 있습니다. 비즈니스 개체는 보안에 대한 로그인 ID와 같은 일종의 시스템 제어를 수행하는 서비스일 수도 있습니다.
- 개념적 모델에서 "선 간 읽기"를 통해 모호한 비즈니스 개체를 만들지 않도록 합니다. 이러한 비즈니스 개체는 올바르지 않을 수 있으며 논리 모델에 포함하기 전에 신중하게 고려해야 합니다. 올바르게 표시되면 개념적 모델에 명시적으로 추가합니다.
- 동일한 정보 또는 함수를 표현하는 비즈니스 개체를 만들지 않습니다. 중복은 애플리케이션 속도 및 성능 측면에서 비용이 많이 들 수 있습니다.
- 개체 종속성을 확인합니다. 개념적 모델의 일부 명사만 다른 비즈니스 개체의 특성일 수 있습니다. 특성이 독립적으로 존재할 수 있는지 여부를 결정합니다. 그렇다면 자체 비즈니스 개체가 되어야 합니다. 그렇지 않은 경우 적절한 비즈니스 개체와 결합해야 합니다.
- 너무 많은 작업을 시도하는 비즈니스 개체를 만들지 마세요. 비즈니스 개체를 오버로드하면 나중에 코드를 분리하는 데 더 많은 시간이 소요될 수 있으며 유지 관리의 골칫거리가 될 수 있습니다. 개념적 모델의 고유 개체는 결합하면 안 됩니다. 별도의 비즈니스 개체로 유지되어야 합니다. 코드를 사용하여 공통 함수를 비즈니스 개체에 위임하여 유사성을 처리할 수 있습니다.
- 사용 시나리오에서 사용되지 않는 비즈니스 개체를 제거합니다. 향후 증가를 수용하기 위한 개체인 경우 초기 애플리케이션이 완료된 후 구현하는 것이 좋습니다.
이 시점에서 컴퓨터 및 코드 측면에서 생각할 수 있습니다. 이러한 비즈니스 서비스에서 사용자 서비스로 제공해야 하는 표시 및 입력 기능을 결정합니다. 데이터 서비스로 제공해야 하는 테이블 및 저장 프로시저를 정의합니다. 논리 모델을 완료하려면 각 서비스에 대한 인터페이스를 정의하고 각 데이터 필드의 정의와 해당 유효성 검사 규칙을 포함합니다. 또한 모든 함수, 해당 구문 및 해당 매개 변수를 포함합니다.
서비스 또는 개체 정의에는 물리적 구현의 어떤 측면도 포함해서는 안 됩니다. 논리 구성 요소 작성기에서 작업하고 다른 프로그래머가 구성 요소가 실제로 완료되기 전에 사용할 수 있는 애플리케이션의 코드를 작성할 수 있도록 명확한 지침을 제공하기 위한 것입니다. 논리 모델 디자인에서는 모든 화면, 함수 및 개체를 문서화해야 합니다. 이러한 조건을 충족할 때까지 물리적 모델 또는 구현을 진행하지 마세요. 개념적 모델 및 논리 모델이 합의되지 않은 동안 계속 진행하면 개발 주기의 뒷부분에서 심각한 문제가 발생합니다.
COM+ 애플리케이션의 증분 개발은 일반적입니다. 여기에는 최종 알려진 구성 요소의 하위 집합을 만들고 애플리케이션의 각 계층(클라이언트, 비즈니스 및 데이터 계층)을 통해 데이터 스토리지로 테스트하는 작업이 포함됩니다. 이 작업 모델은 고객 및 구현 고려 사항의 추가 요구 사항에 대한 인사이트를 제공합니다. 종종 이 작업 모델은 단일 컴퓨터에서 테스트됩니다.
관련 항목