System Architecture
시스템의 구조(structure), 행위(behavior), 뷰(view)를 정의하는 개념 모델로, 각 컴포넌트가 어떻게 상호작용하고 정보를 교환하는지 설명한다.
목적
소프트웨어를 계층으로 나눔으로써 관심사를 분리할 수 있다.
이 때, 계층간 경계를 두어 각 Layer를 분리하고, 관심사를 분리하는데 설명한 방식이 Dependency Rule이다.
Dependency rule
Software를 이루는 서로 다른 영역을 circular diagram으로 나타내었을 때, higher level일 수록 더 안쪽 circle이 되는 형태를 띤다. (outer circle : mechanism, inner circle : policy)
이 때, inner circle은 outer circle에 independent하기 때문에, outer circle의 변화는 inner circle에 영향을 주지 않는다. 반면, inner circle의 변화는 outer circle에 영향을 줄 수 있다.
중요성
이를 통해 다음과 같은 시스템을 생성할 수 있다.
-
Framework-independent한 시스템을 구축할 수 있다.
- System Architecture는 라이브러리 존재 여부나 프레임워크에 한정적이지 않아 도구로써 사용하는 것이 가능하다.
-
테스트가 용이하다.
- Dependency rule을 따름으로써 Business rule이 UI, DB, 웹 서버 등 외부적인 요인들에 영향 받지 않고 테스트될 수 있다.
-
UI에 독립적이다.
- 시스템의 다른 부분을 고려하지 않고 UI를 변경할 수 있다.
-
Db에 독립적이다.
- DB (SQL, MongoDB, CouchDB 등)에 독립적으로 변경될 수 있고, Business rule에 얽매이지 않는다.
-
외부 기능에 독립적이다.
- Business rule은 외부 상황 (DB, UI)에 대해 아무것도 모른다.
Business Rule (Logic)
- 컴퓨터 프로그램에서 실세계의 규칙에 따라 데이터를 생성, 표시, 저장, 변경하는 부분
- UI (Presentation tier) 와 DB (Data tier) 사이에서 발생한 정보 교환을 위한 특정 알고리즘이나 규칙이 정의된 tier
Clean Architecture
크게 Domain, Infrastructure, 그 사이의 Adapter로 구분되어 있고 각 layer는 세분화되어 있다.
위 그림 또한 Dependecy Rule에 따라 작동하여 outer에서 inner로 의존성을 가지게 된다.
Domain
Business rule이 존재하는 영역
- 잘 변하지 않는 안정된 영역
Entities
Application에서 핵심적인 기능인 Business Rule들을 담고 있음
- Class 내의 method 들의 그룹으로 볼 수 있다.
Use Cases
특정 Application에 대한 Business Rule로써, Entity를 사용하여 시스템이 어떻게 자동화될 것인지에 대해 정의하고 Application의 행위를 결정함
- Abstract class나 interface를 정의한다.
(Interface) Adapter
Domain과 Infrastructure 사이의 경계를 관리하는 영역
Controllers
Gateways
Presenters
Infrastructure
UI, DB, web APIs, Devices, Frameworks, External Interfaces 등이 존재하는 영역
- Domain에 비해 자주, 쉽게 바뀔 수 있는 영역
Ref
의존성 역전 원칙 (DIP) https://huisam.tistory.com/entry/DIP
