Layerd Architecture

어플리케이션 코드를 잘 짜는 방법

• 논의하는 방법에 대한 훈련
  • 근거와 해결 방법에 대한 내용
  • 설계 원칙에 대한 팀 내 동기화
  • 코드 평가는 사람에 대한 평가가 아니다

헤리티지와 레거시

• 둘다 관습 및 과거의 산출물을 의미
  • 헤리티지: 비즈니스 로직, 목표, 과거에서부터 가치를 이어가는 것들
  • 레거시: 코드, 현재는 가치를 갖지 않음
• 더 좋은 코드라는 건 동일한 헤리티지에 대해 더 적은 엔트로피를 갖는다는 것

설계 원칙 1

• KISS
  • 처음부터 복잡하게 시도하지마라. 가장 간단한 방법으로 시도해라
  • 특히 MSA 는 명확한 이유가 없으면 하지마라
  • 비대한 모놀리식을 깔끔하게 만들고 MSA로 변경하는게 더 편하다

설계원칙 2

• 참조는 단방향으로

설계원칙 3

• 결과의 국소성
  • 변경 영향이 적은 방향으로 모듈을 나눠야 한다.
  • git conflict가 적게 나는 방향으로
  • 중요한 함수, 변수는 짧을 수록 좋음

설계원칙 6

• 데이터 주권
  • 서비스와 레포지토리는 1대 1로 매칭
  • 도메인끼리 참조할때는 서비스 - 서비스 단에서 연결한다

설계원칙 7

• Container를 통한 의존관계 명세
  • 모듈끼리의 참조관계를 파악하기 좋음
    • 이게 싫으면 모듈 내부의 import를 보던가…
  • 싱글톤: 실제 모듈의 구현. 하나의 클래스는 하나의 객체. 리소스 재활용

설계원칙 8

• SLAP(Single Level of Abstraction Principle)
  • 추상화 수준을 통일해야한다.
  • 인프라 설계 원칙도 동이
  • 동형 원칙
    • 함수나 변수의 이름이 기능과 매칭 되도록 맞춰서 생성하라
      • get ⇒ 무조건 그냥 가져와. 없으면 에러야(필수 데이터에 대한)
      • find ⇒ 찾아보고 있으면 가져오고 없으면 가져오지마(옵셔널한 데이터에 대한)
      • retribe ⇒ 조회하는데 특정 조건이 있고 이것 저것 필요한 것들이 있는데 그걸 통해서 데이터를 가져와
      • by ⇒ 조회 시 조건에 대해 함수에 명세
      • create : insert(있으면 장애), update: update(없으면 장애), save: upsert
  • 열람성, 요약성
    • 코드 함수의 관심 단을 나눈다.
    • 문학적 코딩

설계원칙 9

• 선형 원리
  • if절, 반복문은 적을수록 좋다.
  • 암묵지 회피
    • create 시 db에서 id 생성에 대해 insert 시 select 발생
    • 암묵적인 지식이 생김

설계원칙10

• 코드를 작성하는 코드를 작성하자

테스트 코드 작성 하자

---

퍼사드 디자인 패턴

• 레거시를 제거하기 위한 디자인 패턴

내 하루 코딩 퍼포먼스가 어느정도 나오는지

테스트 코드 작성하는데 어느정도 나오는지에 대한 대략적인 산정을 알면 본인의 작업 역량에 대한 계산이 가능

프론트 협업을 위한 도구

• https://orval.dev/

프로젝트/패키지/모듈

패키지 구조

• 비즈니스 레이어
  • src : 실제 비즈니스 로직
• 프레젠테이션 레이어: 인터페이스 개체
  • webapp(fastapi)
  • GraphQL app(postgraphile)
  • gRCP app
  • scheduler app

레이어드 아키텍처 장단점

장점

• 구조적 단순함. 유지보수성. 가독성.

단점

• 레이어 별로 홉이 많아질수록 어려움
• ETL 파이프라인에는 적합하지 않음

모듈

• 도메인을 기준으로 분리
• 펑션을 기준으로 분리
• 기준은 작업 단위로 분리
  • 펑션 별로 작원 인원을 분리할 것인지. 도메인을 기준으로 나눌것인지