논리적 구조 설계Logical Architecture
📅
UP 아티팩트 관계 예시 (UP Artifact Relationships) 🔗
UP 아티팩트는 논리적 아키텍쳐(LA)에 영향을 미침
- 주요 입력은보충 명세서에 캡쳐된 아케텍처적 힘
논리적 아키텍쳐는 소프트웨어 클래스가 정의되는
패키지
정의UML 패키지 다이어그램 (UML Package Diagram) 🔗
설계 모델
의 일부로 LA를 설명
소프트웨어 아키텍쳐 문서
에서 하나의 view로 요약 가능논리적 아키턱쳐와 레이어 (Logical Architecture and Layers) 🔗
논리적 아키텍쳐
소프트웨어 클래스를패키지,서브시스템,레이어로 대규모 조직하는 것
다른 운영 시스템 프로세스나 네트워크의 물리적 컴퓨터에 배포되는 방법에 대한 결정은 하지 않는다.
레이어
응집된 책임을 가진 클래스, 패키지 또는 서브시스템의강한 결합
상위
레이어는 하위
레이어의 서비스를 호출하지만 그 반대는 아니다.
객체지향 시스템에서 일반적인 레이어: 사용자 인터페이스(UI), 애플리케이션 로직 및 도메인 객체, 기술 서비스엄격한 vs 느슨한 레이어 아키텍쳐 (Strict vs Relaxed Layered Architecture) 🔗
엄격한 레이어 아키텍쳐
한 레이어는 바로 아래에 있는 레이어의 서비스만 호출
네트워크 프로토콜 스택에서 일반적
느슨한 레이어 아키텍쳐
한 레이어는 여러 레이어의 서비스를 호출
예: UI 레이어는 직접 하위의 애플리케이션 로직 레이어뿐만 아니라, 로그 기록 등의 기술 서비스 레이어의 요소도 호출할 수 있다.
정보 시스템에서 일반적
소프트웨어 아키텍쳐란 무엇인가 (What is Software Architecture?) 🔗
소프트웨어 시스템의 근본적인구조와 시스템을 만드는 학문
각 구조는 소프트웨어 요소, 그 관계, 그리고 이들의 속성을 포함
UML 적용: 패키지 다이어그램 (UML Applied: Package Diagrams) 🔗
UML 패키지 다이어그램
은 논리적 아키텍쳐를 설명하는 데 자주 사용됨- 레이어, 서브시스템, 패키지(자바 의미)등을 포함
- 예: UI 레이어는 UI 패키지로 모델링된다.
UML 패키지 다이어그램은 요소를
그룹화
하는 방법을 제공- UML 패키지는 클래스, 다른 클래스, 유스케이스 등 무엇이든 그룹화 가능하다.
- 패키지 중첩은 일반적
패키지 종속성 (Package Dependencies) 🔗
패키지 간의 종속성은 패키지 다이어그램에 표시
- 개발자는 시스템에서 대규모 결합을 식별할 수 있다.
- 패키지 간의 종속성은 패키지 다이어그램에 점선 화살표로 표시 - 종속성 라인(dependency line)
레이어를 사용한 설계 (Designing with Layers) 🔗
시스템의 대규모 논리적 구조를 조직화함
- 명확하고 응집력 있는 관심사의 분리 - 각자 다른 관련된 책임을 가진 개별 레이어로 나눈다.
- 하위레이어는저수준의 일반 서비스 제공,상위레이어는어플리케이션에 특화됨 협업과 결합은 상위 레이어에서 하위 레이어로 진행됨 하위 레이어에서 상위 레이어로의 결합은 피해야 함
예시 (논리적 아키텍쳐의 일반적 레이어) 🔗
- UI (사용자 인터페이스) 레이어
- 애플리케이션 로직(Application Logic) 레이어
- 도메인 객체 (Domain Object) 레이어
- 비즈니스 인프라스터럭쳐 (Business Infrastructure) 레이어
- 기술 서비스 (Technical Services) 레이어
- 기반 (Foundation) 레이어
레이어 사용의 장점 (Benefits of Using Layers) 🔗
관심사, 고수준/저수준, 어플리케이션/일반 서비스 분리
- 결합도와 의존성을 줄임
- 응집력을 향상시킴
- 재사용 가능성 높아짐
- 명확성 증가
관련된 복잡성은 캡슐화되고 분해 가능
일부 레이어는 새로운 구현으로 대체할 수 있다.
- 저수준 기술 서비스나 기본 레이어(java.util 등)에서는 일반적으로 불가능하지만, UI, 애플리케이션, 도메인 레이어에서는 가능하다.
하위 레이어는 재사용 가능한 기능을 포함한다.
일부 레이어(주로 도메인 및 기술 서비스)는 분산될 수 있다.
논리적 분할 덕분에 팀 단위 개발이 용이하다.
도메인 레이어와 도메인 객체 (Domain Layer and Domain Objects) 🔗
도메인 객체
- 실제 도메인과 유사한 이름과 정보를 가진 소프트웨어 객체를 만들고 그들에게 애플리케이션 로직 책임 부여
- 문제 도메인 공간에서 하나의 사물을 나타내며, 관련된 어플리케이션 or 비즈니스 로직을 가진다.
도메인 레이어
- 애플리케이션 로직을 처리하기 위해 도메인 객체를 사용하는 레이어
객체 지향 개발자는 소프트웨어 클래스를 생성하기 위해 실제 도메인에서 영감을 얻는다.
이해 관계자가 도메인을 인식하는 방식과 소프트웨어에서의 표현 간의 간극이 줄어든다.
티어, 레이어, 파티션 (Tiers, Layers, and Partitions) 🔗
티어
- 물리적처리 노드(또는 노드 클러스터)를 의미하는 소프트웨어 컴포넌트
- 클라이언트 티어(클라이언트 컴퓨터)와 같은 의미
레이어
- 시스템의 수직적 구획
파티션
- 상대적으로 평평한 하위 시스템(레이어)의 수평적 구분
예를 들어, 기술 서비스(Technical Service) 레이어는 보안(Security) 및 보고(Logging)와 같은 파티션으로 나눌 수 있다.
모델-뷰 분리 원칙 (Model-View Separation Principle) 🔗
- 비 UI 객체를UI 객체에 직접 연결하거나결합하지 않는다.
- 애플리케이션 로직을UI 객체 메서드에 넣지 않는다.
SSD, 시스템 운영, 레이어 간의 연결 (Connection between SSD, System Operations, and Layering) 🔗
잘 설계된 아키텍쳐에서,
- UI 레이어객체는 UI 레이어(시스템 운영)의 요청을도메인 레이어로 전달하거나 위임한다.
- UI 레이어에서 도메인 레이어로 보내는 메시지는 SSD에 설명된 메시지일 것이다.