layered architecture (수정중)

https://jonnung.dev/book/2022/01/23/book-review-architecture-patters-with-python-part1/
https://www.oreilly.com/library/view/architecture-patterns-with/9781492052197/
https://www.notion.so/Microservice-Inner-Architecture-f15c8c29d9954480b1d85e491058cfad
https://www.youtube.com/watch?v=EGzQvBqhUS0

clean architecture

• 클린 아키텍쳐에서는 layer를 나눕니다
• 외부세계 , 어플리케이션 ,도메인으로 보통 나눔
• local dto: 도메인 모데일이 어플리케이션 밖인 컨트롤러 까지 노출
  도메인 모델의 로직이 과도하게 노출 될 가능성
  도메인 모델에 대한 영향들 덜 받음

0. 서비스 계층

• 저장소에서 어떤 객체를 가져온다
• 요청을 검사
• 도메인 서비스를 호출
• 정상적으로 실행됐으면 저장 ,업데이트한다
• 어플리케이션 서비스(서비스 계층) : 외부에서 오는 요청을 오케스트레이션
• • db에서 데이터를 얻는다
• • 도메인 모델을 업데이트
• • 변경된 내용을 저장
• 도메인 서비스 : 도메인 모델에 속하지만 , 근본적으로 상태가 있는 엔티티나 값 객체에 속하지 않는 로직을 부르는 이름
• 서비스 계층 : 앤드포인트 라인 수가 줄어들고 , 단지 json , http 코드 반환과 같은 웹 기능만 수행
• • 서비스 계층으로 잉ㄴ해 테스트를 높은 거이비로 작성 가능
• • 도메인 모델을 마음것 리팩터링 할 수 있다

1. domain

• 가장 일반적인 아키텍쳐 패턴은 n 계층 아키택쳐 패턴

패턴 설명

• 계층화된 아키텍쳐 패턴의 각 계층에는 애플리케이션 내에서 특정 역할과 책임이 있음
• presentation layer:
  모든 사용자 인터페이스와 브러우저 통신 논리를 처리
• busienss layer:
  요청과 관련된 특정 비지니스 규칙을 실행하는 역할을 함
• 계층화된 아키텍쳐 패턴의 강력한 기능 중 하나는 구성 요소 간 관심 분리
• 특정 계층 내에 구셩오소는 해당 계층과 관련된 논리만 처리
• 이 아키텍쳐 패턴을 사용하여 애플리케이션을 쉽게 개발 ,테스트 ,통제 및 유지 관리 가능
• 위에서 아래로만 진행 가능 (프레젠테이션 게층이 지속성 계층이나 데이터베이스 계층에 대해 직접 엑세스 허용X)

  아니 근데 왜 이렇게 귀찮게 만들어요?

  * 단순히 프레젠테이션 레이어에서 직접 퍼시스턴스 레이어 연결하면 더 빠르자나요
  * 레이어 격리 개념은 아키텍쳐의 한 레이어에서 이루어진 변경이 일반적으로 다른 레이어 구서용소에 영향을 미치지 않음ㅌ

  • 직접 엑세스 허용하면 지속 계층 내에 sql에 대한 변경 사항이 비지니스 계층과 프레젠테이션 계층 모두 크게 영향을 미침
  • 이러면 결합도가 올라가고 결과적으로 코스트가 오라감
  • 닫힌 레이어는 격리 레이어를 용이하게 하므로 아키텍쳐 변경을 격리하는데 도움

고려사항

• 싱크홀 방지 패턴
  이 안티 패턴은 요청이 아키텍쳐 여러 레이어를 통해 흐르는 상황을 각 레이어 내에서 수행되는 로직이 거의 없는 단순한 통과 처리
  일반적으로 20%는 단순 통과처리 , 80%는 요청과 관련된 일부 비지니스 로직이 있음

  

repository pattern

• 핵심 논리 인프라 문제와 분리하는 방법으로 dip원칙을 사용
• 데이터 저장소에 대해 추상화를 단순화하는 리포지팩토리 패턴을 도입하여 모델 계층을
  데이터 계층에서 분리
• 데이터베이스의 복잡성을 감춰서 시스템 테스터 용이
• 도메인 모델에서는 그 어떤 의존성도 없어야 됨

결합과 추상화

• 저장소 패턴은 영구 저장소에 대한 추상화
• b컴포넌트가 깨지는게 두려워서 a컴포턴트를 변경할 수 없는 경우 이 두 컴포넌트가 서로 결합되어 있다고 한다
• 지역적 결합은 좋은것 ,하지만 전역적 결합은 성가신 존재
• 추상화란
  저장소 패턴은 영구 저장소에 추상화 , 좋은 추상화를 만드는것은 어떤 것 ?
• 추상화를 통해 지저분한 세부 사항을 숨길 수 있음

flask 예시

• 오케스트레이션 로직 , 비지니스 로직 , 인터페이스 , 테스트 코드
• 서비스 계층을 데이터베이스에 대한 저장소 추상화와 결합하여 도메인 모델뿐만 아니라 사용사례에 대한 전체 워크플로우에 빠른 테스트를 작성 할 수 있음
• 서비스 계층은 abstracyRepository를 사용하여 단위 테스트 수행
• 도메인 모델의 핵심과 주문을 할당하는데 필요한 도메인 서비스가 있음
• 도메인 모델 핵심과 주문을 할당하는데 필요한 도메인 서비스 , 영구 저장을 위한 저장소 인터페이스
• 움직이는 모든 부분을 빨리 연결 , 더 깨긋한 아키텍쳐로 리펙토링

flow

1. allocateFlask 를 사용하여 도메인 서비스 앞에 api 엔드포인트를 배치
2. 데이터베이스 세션과 저장소 연결
3. 테스트 데이터를 준비하기 위해 중단간 테스트와 빠르고 간단한 sql 로 테스트
4. flask 도메인 모델 사이에 위치할 서비스 계층을 리펙토링 FakeRepository

• 서비스 계층 도입 , fakerepository를 사용하여 단위 테스트

Tdd

• 서비스 계층에 대해 테스트하면 더는 도메인 모델 테스트가 필요없다
• 테스트가 있으면 , 시스템을 바꾸는데 두려움이 없다
• 하지만 도메인 모델에 대한 테스특 ㅏ너무 많으면 , 코드 베이스를 바꿀 때마다 많은 테스를 변경해야하는 문제가 생김
• api에 대해 테스트를 작성하면 도메인 모델을 리펙터링할 떄 변경해야 하는 코드의 양을 줄일 수 있음
• • 서비스 계층에 대해 테스트만 수행하도록
• • 직접 모델 객체의 사적인 송성이나 메서드 테스트 직접

Harry Says: Seeing a Test Pyramid in Action Was a Light-Bulb Moment
Here are a few words from Harry directly:

I was initially skeptical of all Bob’s architectural patterns, but seeing an actual test pyramid made me a convert.

Once you implement domain modeling and the service layer, you really actually can get to a stage where unit tests outnumber integration and end-to-end tests by an order of magnitude. Having worked in places where the E2E test build would take hours (“wait ‘til tomorrow,” essentially), I can’t tell you what a difference it makes to be able to run all your tests in minutes or seconds.

Read on for some guidelines on how to decide what kinds of tests to write and at which level. The high gear versus low gear way of thinking really changed my testing life.

unit of work pattern

• 작업 단위 패턴은 저장소와 서비스 계층 패턴을 하나로 묶어주는 패턴
• 저장소 패턴이 영속적 저장소 개념에 대한 추상화 , uow 패턴은 원자적 연산이라는 개념에 의한 추상화
• uow 패턴을 사용하면 , 서비스 계층과 데이터 계층을 완전히 분리 할 수 있음
• repository and service layer patterns Unit of Work pattern
• Uow patterns is our abstranction over the ida of atomic operation
• it will aloow us to finllay and decouple our service layer from the data layer
• • 작업 단위 패턴은 저장소와 서비스 레이어를 묶어주는 패턴이다
• • uow가 없는 경우 어플리케이션은 직접 db 세션을 시작하고 저장소 레이어를 연결해 서비스 레이어에 할당을 요청 -> 할 일이 많아짐
• • 업데이트 비용이 많은 경우에 효울적
• • 어플리케이션이 최대한 본연의 일만 하도록 uow가 db세션 관리 , 저장소 역할을 맡는다
    어플리케이션 -> 서비스 레이어 -> 저장소 레이어 -> db
    어플리케이션 -> 서비스 레이어 -> uow -> 저장소 레이어 -> db
    db세션 저장소 연결은 uow에서 관리하니 어플리케이션 앤드포인트 함수는 훨씬 간결
• uow으로 연산의 끝에 플러시 연산을 한번 더 수행하게 되어 모델의 일관성 ,성능 향상
• Uow는 저장소 ,서비스 레이어와 밀첩하게 연결되어 작동한다