논리적 구조 설계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에 설명된 메시지일 것이다.