로버트 마틴이 정립한 용어로, 외부 인터페이스에 독립적으로 구현할 수 있도록.
계층형 아키텍쳐가 가지던 의존성에서 벗어나게 설계를 제공한다.
바깥 레이어가 정해지지 않아도 서비스를 구축할 수 있도록 제공
아키텍쳐들은 디테일한 부분은 모두 다르지만, 매우 유사하다. seperation of concerns 라는 공통 목적이 있다.
소프트웨어를 계층으로 나누어 역할분리. 각각 비즈니스 계층, 인터페이스 계층은 적어도 하나 있다.
이러한 아키텍쳐는 다음과 같은 system을 생성한다.
-
프레임 워크와 독립적.
아키텍처는 기능이 많은 소프트웨어의 라이브러리 존재에 의존하지 않는다. 시스템을 제약 조건에 넣기보단, 이러한 프레임워크를 도구로 사용할 수 있다.
-
테스트 가능
비즈니스 룰은 UI, Database, Web server 등 기타 외부 요소 없이 테스트 할 수 있어야 한다.
-
UI와 독립적
시스템의 나머지 부분을 변경하지 않고 UI를 쉽게 변경할 수 있어야한다. 예로 비즈니스 모델을 바꾸지 않고 웹 UI → 콘솔 UI로 변경할 수 있어야 한다.
-
데이터베이스와 독립적
비즈니스 규칙은 데이터베이스와 연결되지 않아야한다.
-
external agency와 독립적
비즈니스 규칙은 외부 세계에 대해 전혀 알지 못한다.
→ 이런 아키텍쳐들을 단일 개념으로 통합하고자 하는 시도
위의 사진의 원들은 소프트웨어의 각기 다른 영역을 나타낸다. 바깥쪽일 수록 고수준의 소프트웨어가 되며 메커니즘이고, 안쪽원은 정책이다.이 아키텍쳐를 가능하게 하는 중요한 규칙이 바로 의존 규칙(Defendency Rule) 이다.
이 규칙에 의해 안쪽을 향해서만 의존하고, 안 → 밖에선 전혀 알지 못한다.바깥쪽 원에서 선언된 어떠한 이름을 안쪽 원에서 참조해서는 안된다.
바깥쪽 원에서 사용하는 데이터 포멧을 안쪽 원에서 사용하지 않아야한다.
(계속 강조하고 있는 부분은 안쪽 원은 바깥쪽 원을 전혀 모르며, 의존성 방향은 바깥에서 안쪽으로)
엔티티는 대규모 프로젝트 레벨의 비즈니스 규칙을 캡슐화 한다. 엔티티는 메서드를 갖는 객체일 수도 있지만, 데이터 구조와 함수의 집합일 수도 있다.
엔티티는 가장 일반적이면서 고수준의 규칙을 캡슐화 한다. 바깥쪽 무엇이 변경되더라도 바뀌지 않는다. 예를들어 보안사항이나 화면 변경으로 인해서 엔티티 객체는 전혀 영향 받지 않는다. 애플리케이션의 동작에 관한 변경이 엔티티 계층에 영향을 주어선 안된다!
- 고수준 : 어떤 의미 있는 단일 기능 제공 모듈, 상위 수준(큰 틀)에서 프로그램 다룸
- 저수준 : 고수준 기능 구현을 위한 하위 기능의 실제 구현, 각 개별요소의 구현에 집중
https://koseungbin.gitbook.io/wiki/books/undefined/part-2.-di/solid/dependency-inversion-principle
이 계층은 고유 비즈니스 규칙을 포함하며, 시스템의 모든 Usecase를 캡슐화하고 구현한다.
Entity로 부터 or Entity에서의 데이터 흐름을 조합한다. 프로젝트 레벨의 규칙을 사용해 Usecase의 목적을 달성하도록 지휘한다.
이 계층 변경이 엔티티에 영향 주지 않고, 공통의 프레임워크 변경으로부터 영향 받지 않을 것을 기대한다.
하지만 애플리케이션 조작에 대한 변경은 Usecase에 영향이 있고, 따라서 소프트웨어 영향이 있을 것을 기대한다.
Usecase와 Entity에 있어 용이한 형식으로 데이터베이스나 웹 외부 기능에 용이한 형식으로 데이터 변환한다.
(약간 내가 사용하는 Presenter 영역이랑 비슷한가?)
GUI의 MVC 아키텍처를 완전히 내포한다. Presenter, View, Controller 모두 여기 속함 (맞구만..)
Model은 Controller → Usecase로 전달되고 Presenter나 View로 되돌아가는 그저 단순한 데이터 구조일 가능성이 높다.
이 계층의 데이터는 Entity, Usecase에서 용이한 형태 → 사용하고 있는 프레임 워크의 용이한 형태로 변환
예를 들어, 데이터베이스에 관해 아는 것이 없어야한다. 만약 데이터베이스가 SQL 이라면, 어떤 SQL인지 제한 없음!
가장 바깥 계층은 DB나 웹 프레임워크 등 일반적으로 프레임워크나 도구로 구성.
안쪽의 원과 연결 코드이외엔 별다른 코드 작성X
이 계층은 상세한 정보가 무엇이든 여기둔다. 웹과 DB모두 상세하지만, 이런 것으로 영향 주지 않도록 밖에 유지
소스코드의 의존성은 항상 안쪽으로 향해야 함
안쪽으로 갈 수록 추상화 수준 올라감
- 추상화 높다 : 나 오늘 프로그래밍 공부했어.
- 추상화 낮다 : 나 오늘 python 반복문에 대해서 공부했어.
가장 바깥쪽 원은 저수준의 구체적인 상세 정보를 담는다.
안쪽으로 이동해가면서 추상화되고, 고수준의 정책 캡슐화, 일반성이 있음
Controller(밖) → Usecase(안) → Presenter(밖)
-
의존성은 안쪽으로만 향해야 하는데 이 경우는 역전됨
인터페이스로 (Swift의 프로토콜)로 상속 관계를 조합해 제어 흐름이 반대하도록 함.
ex) Usecase → Presenter를 호출
직접 호출은 안된다. 의존성에 위반되므로 안 → 밖 호출은 안됨
-
Usecase Interactor를 구현해서 흐름을 역전해 구현
동적인 다형성의 이점을 이용해 소스코드의 의존성이 제어흐름의 반대가 되도록할 수 있다. → 제어 흐름이 어떤 방향이든 상관없이 의존성 지킬 수 있다.
경계를 넘나드는 데이터 구조는 단순한 데이터 구조의 데이터
- 기본적인 구조체, 단순한 DTO(Data Transform Object)를 취향에 맞게 사용가능
- 격리된 단순한 구조의 데이터가 경계를 넘어간다.
- 경계를 넘어 데이터를 전달할 땐 항상 안쪽 원의 다루기 쉬운 데이터 형식이어야 함.
내 고민점과 동일한 글 발견!!
- 개발팀 외부 사업부서가 알고 있어야 하는 로직인가? 의 차이
- 비즈니스 로직 = 앱의 사용자 상호작용(X), 업무 요구사항(O)
나도 프로젝트를 하면서.. 그냥 API로 데이터 받아 뿌리기만 하는 앱에 비즈니스 로직이 있나? 라는 의문이 들었고, 몰라서 어떻게든 찾아 넣으려고 했던 경험이 있다. (패턴에 맞춰서)
글을 참고하니, 굳이 유스케이스 만들기보단, 일부는 레포지토리로 프레젠터로 흡수시켜도 된다고 한다!
이것도 마찬가지로 같은 이유다. 샘플 프로젝트의 규모가 너무 작은데, 많은 레이어의 아키텍처를 끼워맞추려다보니 발생한 문제다.. 굳이 변환해서 오버헤드 발생 필요 없이 모델 통일해도 된다고 한다!