좋은 아키텍처를 만들기 위한 가이드 및 원칙을 보여주는 책자

아키텍처의 목표는 필요한 시스템을 만들고 유지 보수 하는데 필요한 인력을 최소화 하는데 있다

• 소프트웨어의 중요한 두 가지

  • 행위: 기능 명세서나 요구 사항 문서를 구체화 할 수 있도록 돕는다
  • 구조: 위의 행위를 유연하게 변경할 수 있도록 하는 구조

• 프로그래밍 패러다임의 종류

  • 구조적: 제어 흐름의 직접적인 전환에 대해 규칙을 부여하는 방식 . 구조적 분해가 핵심
  • 객체 지향: 제어 흐름의 간접적인 전환에 대해 규칙을 부여 . 다형성이 핵심
  • 함수형: 할당문이 전혀 없다. 할당문에 대해 규칙을 부여. 불변성이 핵심

• 좋은 아키텍처를 위한 클래스 기반 원칙

  • SOLID: 변경에 유연하고, 이해하고 쉽고, 많은 시스템에 사용 가능한 원칙
  • 위의 원칙을 아키텍처의 관점에서 바라보고 해석
  • SRP
    • 하나의 모듈은 하나의 액터에 대해서만 책임져야 한다
    • 많은 사람의 하나의 코드를 수정하는 사항이 생길 때 이 규칙은 깨져 있다
    • 해결책은 메서드를 각기 다른 클래스로 이동하고, 데이터를 분리하는 것이다
  • OCP
    • 확장(기능 변경)에는 열려있고, 변경(코드 임팩트)에는 닫혀있어야 한다
    • 고수준의 모듈이 저수준에 직접 의존하는 경우에 깨진다
  • LSP
    • 자식 객체를 사용하는 자리에 부모 객체로 대체하더라도 정상 동작해야 한다
    • 이는 자식 객체만 가지고 있는 Public Method가 존재해서는 안된다
  • ISP
    • 필요 이상으로 많은 인터페이스를 노출하지 마라
    • SRP 원칙을 지킨다면 문제 되지 않을 것이다
  • DIP
    • 참조하는 형태는 반드시 인터페이스나 추상 클래스여야 한다
    • 안정된 추상화의 원칙
      • 변동성이 큰 구체 클래스를 참조하지 마라.
      • 추상 팩토리를 사용하라
      • 변동성이 큰 클래스를 상속하지 마라
      • 구체화된 함수를 오버라이드 하지 마라

• 좋은 아키텍처를 위한 컴포넌트(패키지) 기반 원칙

  • 컴포넌트: 배포의 단위
  • REP: 재사용/릴리즈 등가의 원칙
    • 재사용 단위는 릴리즈 단위와 같다
    • 단일 컴포넌트는 응집성 높은 클래스와 모듈로 구성되야 한다는 원칙
  • CCP: 공통 폐쇠 원칙
    • 동일한 이유로 동일한 시점에 변경되는 클래스는 같은 컴포넌트이다
  • CRP: 공통 재사용 원칙
    • 사용자들이 필요로 하지 않는 것을 서로 묶지 마라
  • ADP: 의존성 비 순환 원칙
    • 컴포넌트 의존성 그래프에 순환이 있어서는 안된다
    • 순환이 생기면 컴포넌트를 분리하기 가 어려워진다
    • 해결책
      • DIP를 이용하여 의존성 방향을 전환한다
      • 순환되는 두 클래스가 이용하는 새로운 컴포넌트를 생성한다
  • SDP: 안정된 의존성 원칙
    • 컴포넌트는 더 안정적인 컴포넌트에 의존해야 한다
    • 안정적 = 본인을 의존하는 컴포넌트는 많고, 사용하는 컴포넌트는 적은 컴포넌트
    • 인터페이스는 이러한 이유로 분리되는 것이 좋다고 생각한다
  • SAP: 안정된 추상화 원칙
    • 컴포넌트는 안정된 정도만큼만 추상화되어야 한다
    • 즉, 안정적인 컴포넌트는 인터페이스와 추상클래스로 구성되어 확장이 쉬워야 한다

• 아키텍처

  • 시스템을 구축했던 사람들이 만들어낸 형태
  • 유스케이스, 기능, 시스템의 필수 행위를 1급 엔티티로 격상시켜야 한다
  • 세부사항(DB, 프레임워크 등등)의 결정을 최대한 뒤로 미룰 수 있게 개발해야 한다
  • 아키텍처가 하는 일: 유스케이스 발견/개발, 운영, 개발, 배포 지원
  • 처음에는 중복이라도 두 코드의 영역이 각자의 경로로 발전한다면 중복이 아니다 → 결국 액터가 누구냐가 큰 영향을 미친다
  • 정책
    • 업무를 구현하는 핵심. 어떻게 구현해야 할 지를 정한다
    • 동일한 시점에 변경되는 정책은 동일 위치, 컴포넌트에 위치해야 한다
  • 엔티티
    • 핵심 규칙과 데이터를 포함하는 객체
    • 전사적인 핵심 업무 규칙을 캡슐화한다
    • 이 때의 유스케이스는 시스템이 어떻게 보일지 설명하지 않는다
    • Plain Old Object 로 설계되어있어야 한다

• 경계와 계층

  • 아키텍처는 경계를 긋는 기술이다
  • Database Repository 인터페이스는 비즈니스 룰에 속해야 하며, 그 구현체는 Persistance 레이어에 속해야 한다
  • 경계선을 그리기 위해서는 컴포넌트 단위 분할이 먼저 이루어지고 , 핵심 업무와 관련 없는 나머지 업무가 핵심 업무 컴포넌트를 가르키게 된다
  • 부분적 경계
    • 경계를 만드는 비용이 매우 크기 때문에 부분 경계를 만들어 낼 수 있다
    • 일차원 경계
      • 단방향의 인터페이스만을 생성하여 사용하는 방식
      • 개발자가 충분히 훈련되어 있지 않다면 결국 무너진다
    • 퍼사드
      • 의존성 역전까지도 희생하여 경계를 얻는 방법
      • 다만 REP 원칙을 희생한다

• 메인 컴포넌트란?

  • 가장 세부적인 사항을 구현하고, 낮은 수준의 정책을 가진다
  • 팩토리, 전략, 시스템 설정과 같은 많은 부분을 결정하고 높은 수준의 정책으로 제어권을 넘기는 역할을 한다

• 서비스

• 테스트