이제까지 django를 하면서 자료구조 형태를 신경 쓰기 보다는 로직을 restful한 로직을 구현하는 공부를 해왔다.
flask를 공부하게 되면서 django가 얼마나 우리가 해야할 일을 해주고 있었는지에 대해서 알게 되었다. flask를 초기 세팅 하면서 자료 구조를 어떻게 해야 할지 많은 고민을 하게 되었고 그 중 Layered Arcitecture가 되었다.
코드 구조의 중요성
특별한 코드의 구조 없이 한 파일에 모든 코드를 구현하는 것은 코드의 양이 많지 않을 때는 간단하다는 장점을 주릴 수 있으나, 코드의 양이 조금만 많아져도 간단하다는 장점을 잃게 된다.
그래서 논리적으로 혹은 기능 적으로 영역을 구분하여 코드를 관리하는 것이 좋다.
그럼 어떤 특성을 가진 code architeture가 체계적이고 효율적인 아키텍쳐 일까?
-> 확장성(extensiblity), 재사용성(reuseablity), 보수유지가능성(maintability), 가독성(readability), 테스트가능성(testability)
1. 확장성(extensibility)
어떤 코드든 시작은 소규모로 시작하지만, 점점 서비스가 커지게 되면서 코드의 양도 많아지고 규모도 커지게 된다. 그래서 확장성을 고려하지 않은 코드를 구현하게 되면 문제가 많이 생길 확률이 높다.
2. 재사용성(reuseability)
코드의 양도 적어지고, 개발의 속도고 높아지며, 코드 또한 더 안전하고 견고한 코드를 구현하고 싶다. 함수나 클래스를 재사용하는 수준의 재사용성보다는 구조적인 재사용성을 이야기한다.
3. 보수유지 가능성(maintability)
보수유지는 두말할 필요 없이 중요한 요소이다. 이러한 기능을 가지기 위해서는 구조적으로 로직이 잘 정리가 되고 나뉘어 있어야 한다. 그러므로 함수나 클래스 등을 사용하여 코드를 추상화(abstraction)하고, 서로 독립적인 로직을 분리하여 필요한 곳에 적절하게 사용되도록 하는 코드를 구현해야 한다.
4. 가독성(readability)
읽히기 쉬운 코드가 좋으 코드인 줄은 누구나 다 알고 있다. 어려운 로직을 쉽게 간단하게 구현하는 것이 좋은 개발자이다. 또한 코드의 구조 또한 이해하기 쉽게 구현해야 한다.
5. 테스트가능성(testability)
테스트를 잘 구현하기 위해서는 unit test를 하기 쉬운 코드로 구현해야 한다.
이러한 5가지의 요소를 가진 code arcitecture를 구현하도록 노력해야 한다.
위의 요소들을 다 고려해서 backend API 코드에서 가장 많이 쓰이는 구조가 Layered Arcitecture 이다.
Layered Arcitecture
System Arcitecture
시스템의 구조, 행위, 뷰를 정의하는 개념모델 입니다. 많은 System Arcitecture가 나왔지만 결국 그들의 목적은 하나이다. 관심사의 분리
관심사의 분리
분리를 목적으로 가진 구조는 이런 시스템을 형성하게 됩니다.
1. 프레임 워크의 독립성
System Arcitecture는 라이브러리 존재 여부나 프레임워크에 한정적이지 않고 도구로서 사용하는 것이 가능 합니다.
2. 테스트 용이
Business Rule은 UI, DB, Web Server등 기타 요인과 관계 없이 테스트 가능합니다.
3. UI 독립적
시스템의 다른 부분을 고려하지 않고 UI를 변경 할 수 있습니다.
4. Database의 독립성
DB 또한 독립적으로 변경할 수 있으며(SQL, MongoDB, CouchDB 등), 이는 Business Rule에 얽메이지 않습니다.
5. 외부기능 독립적
Business Rule은 외부 상황(DB, UI)에 대해서 아무것도 모릅니다.
clean Arcitecture
Domain
Domain Layer는 Business Rule 이 존재하는 공간 입니다.
Business Rule
application의 특정 부분을 뜻하며 application이 어떻게 작동하는지에 대한 행동을 나타냅니다.
다시말해서 유저의 입력(UI)과, DB사이에서 발생한 정보교환을 위한 특정 알고리즘이나 규칙이 정의된 tier입니다.
Infrasturcture
UI, Database, webAPI, Framworks 등이 존재하는 영역 입니다.
Domain에 비하여 자주, 쉽게 바뀔 수 있습니다.
Dependency Rule
지금 내용 중에서 가장 중요하다고 생각 되는 부분이다.
모든 소스코드의 의존성은 outer에서 inner로, 고수준 정책을 유지해야 한다.
inner circle 에 해당하는 Domain 은 outer circle 에 해당하는 Infrastructure 에 대해서 아무것도 모릅니다.
이는 UI, DB 는 Business Rule에 의존하지만 Business Rule은 그렇지 않다는 것입니다.
위의 그림을 더욱 쪼개 보면
Domain -> Entity, Use Case
Infrastucture -> Presenter, UI
이런식으로 쪼갤 수 있다.
Entity
가장 않에 있는 부분으로서 application에서 가장 핵심적인 부분을 담고 있습니다.
ex) user
Use Cases
특정 application에 대한 Business Rule이다. Use cases는 시스템 Use cases 는 Entities 에 의존하는 동시에 상호작용 합니다. 물론 outer layer 에 대해서는 아는 게 없습니다. 다시 말해 Entity의 User로 만든 로직을 의미합니다.
Infrastructure
Infrastructure 는 모든 I/O components (UI, DB, frameworks, devices) 가 있는 곳입니다. 이는 변화될 가능성이 매우 높기 때문에 stable 한 domain 과는 확실히 분리가 되어있고, 그렇기 때문에 비교적 쉽게 변화되고 component 또한 쉽게 교환됩니다.
위에 이야기 했듯이 의존성이 Outer에서 inner로 화살표가 이루어 진다.
User cases는 Entity를 참조하여 무슨일이 일어나는지 알지만 Entitiy는 User cases에서 무슨일이 일어나는 지 모른다는 것이다.
이러한 성향을 가지고 Layered Arcitecture를 이해 해야 한다.
Layered patteren
- presentation layer, business layerm persistence layer
Presentation layer
사용하는 사용자 혹은 클라이언트 시스템과 직접적으로 연결되는 부분이다. API 부분이 여기에 해당하며 엔드포인트들을 정의하고 전송된 HTTP요청들을 읽어 들이는 로직을 구현한다.
하지만 그 이상의 역할은 하지 않는다.
Business Layer
실제 시스템이 구현해야 하는 로직들을 이 레이어에서 구현하게 된다.
ex) 비밀번호가 300자가 넘으면 오류르 뿜어야하는 로직을 구현하는 장소가 여기이다.
persistence layer
데이터베이스와 관련된 로직을 구현하는 부분이다. 데이터 생성, 수정, 읽기 등을 처리하여 실제로 데이터베이스에서 데이터를 저장, 수정, 읽기 들이기를 하는 역할을 한다.
Layered Arcitecture 핵심요소
단방향 의존성
각각의 레이어는 오직 자기보다 하위에 있는 레이어에만 의존한다.
즉,
presentation layer는 business layer에 의존하고, business layer는 persistence layer에 의존한다.
다시말해
business layer는 presentation layer에 대해 완전히 독립적이며, persistence layer는 business layer나 presentation layer에 대해 완전히 독립적이다.
위 그림에서 화살표를 생각하면 편하다
seperation of concerns
각 레이어의 역할이 명확하다는 뜻이다.
Presentation layer 에는 business layer에 관련된 로직이 전혀구현 되어 있지 않다. 처리하기 위해선 business layer의 코드를 호출해서 사용해야 한다. business layer가 persistance layer의 코드를 사용하고 싶어도 마찬가지 이다.
이러한 이유로 Layered Arcitecture의 구조로 코드를 구현하면
- 코드의 확장성이 높아지고
- 서로에게 끼치는 영향을 최소화 하면서 확장하거나 수정 할 수 있따.
- 각 레이어가 완벽하게 분리되어 있고 역할이 명확하므로 가독성도 높아진다.
- 코드의 구조 파악이 쉬울 뿐만 아니라 각 레이어의 코드의 목적이 명확하고 범위도 확실하기 때문이다
- 재사용 가능성이 높아지고, 이미 명확한 역할에 의해 나뉘어 있으므로 각 레이어를 테스트 하는 코드를 구현하기도 쉽다.
적용해 보기
api - view, sevice, model, app.py
presentation layer -> view(endpoint 부분)
business layer -> service(비즈니스 로직 부분)
persistence layer -> model(데이터베이스 접속 부분)
flask 특성상 db를 직접 연결을 해주어야 하기 때문에 db 테이블과 migration 파일을 모아놓은 폴더를 만들어 주었다.
그리고 chatbot-api를 만드렁서 model, service, view를 만들어 주었다.
아직 구조의 틀만을 잡아 놓은 거라서 단순하지만, 점점 확장할 예정이다.
출처 - 깔끔한 파이썬 탄탄한 백엔드 - 저자 송은우
