Skip to content

Latest commit

 

History

History
135 lines (97 loc) · 10.4 KB

Ch11.md

File metadata and controls

135 lines (97 loc) · 10.4 KB
Raw

Ch 11. Systems

생각 공유

@ChanhuiSeok

11장은 높은 추상화 수준(시스템 수준)에서도 코드의 깨끗함을 유지하는 방법에 대해 말하고 있다. AOP 부분은 다시 한 번 볼 예정이다.

  • 시스템 제작과 사용을 분리하라.

    • 시작 단계 : 모든 애플리케이션이 풀어야 할 관심사. 관심사 분리는, 가장 오래되고 가장 중요한 설계 기법 중 하나. 체계적이고 탄탄한 시스템을 만들려면 흔히 쓰는 좀스럽고 손쉬운 기법으로 모듈성을 깨지 말자.

  • main 분리

    • main 함수에선 시스템에 필요한 객체를 생성하고, 애플리케이션에 넘긴다. 애플리케이션은 main이나 객체가 생성되는 과정을 전혀 모르고 단지 모든 객체가 적절히 생성되었다고 가정한다.

  • 팩토리

    • 객체가 생성되는 시점을 애플리케이션이 결정할 필요가 생길 수도 있다. 애플리케이션이 인스턴스가 생성되는 시점을 완벽하게 통제하지만 생성되는 구체적인 방법은 모른다. (추상 팩토리 패턴)

  • 의존성 주입(DI) - 클래스 밖에서 내부에 의존성을 주입해주는 것. → 의존성은 한 객체가 다른 객체를 사용할 때 의존성이 있다고 말한다.

    • 의존성 주입은 제어 역전(IoC) 기법을 의존성 관리에 적용한 메커니즘이다. ✏️ spring 공부를 잠깐 했었을 때 IoC, DI에 관해서 읽었던 적이 있다. 객체 인스턴스를 외부에서 만들고, 그것을 클래스에 주입한다. 그러면 그것이 제어 역전 기법에 해당하는데, IoC는 객체에 대한 제어 권한이 외부(container)에 있다고 하여 붙은 말이다. IoC가 DI를 포함하는 개념이다.
    • 의존성 관리 맥락에서 객체는 의존성 자체를 인스턴스로 만드는 책임은 지지 않는다. ✏️ 예를 들어 어떤 controller 안에서 객체 인스턴스를 직접 생성하지 않고, 밖에서 생성한 인스턴스를 가져와 활용한다(외부에서 의존성을 가져온다).

  • 확장

    • 소프트웨어 시스템은 물리적인 시스템과 달리, 관심사를 적절히 분리해 관리한다면 소프트웨어 아키텍처는 점진적으로 발전할 수 있다. ✏️ 관심사 분리.. 하나의 관심사는 하나의 기능(역할)만 가지도록 구성하자.
    • 횡단 관심사 : 여기 설명을 참고했다. https://choi3950.tistory.com/32 , 즉 은행 프로그램에서 핵심 관심사항이 입금, 출금 등의 기능이라면, 횡단 관심사는 그들이 공통적으로 가지는 예외처리, 보안처리, 세션 유지, … 와 같은 역할들이라고 보면 된다. 이 횡단 관심사들을 관점(aspect)으로 캡슐화하여 모듈화해서 관리하자는 것을 AOP라고 한다. (참고 : AOP-관점 지향 프로그래밍)

  • 의사 결정 최적화 : 모듈을 나누고 관심사를 분리하면 지엽적인 관리와 결정이 가능해진다.

  • 명백한 가치가 있을 때 표준을 현명하게 사용하라.

  • 시스템은 도메인 특화 언어가 필요하다.

  • 결론은 시스템 역시 깨끗해야 한다. 깨끗하지 못한 아키텍처는 도메인 논리를 흐리며 기민성을 떨어뜨린다. 모든 추상화 단계에서 의도는 명확히 표현해야 한다. 시스템을 설계하든 개별 모듈을 설계하든 실제로 돌아가는 가장 단순한 수단을 사용해야 한다는 사실을 명심하자.

@jjangsungwon

느낀 점

  • 높은 추상화 수준, 즉 시스템 수준에서도 깨끗함을 유지하는 방법을 알려주는 챕터였다. 처음에 읽었을 때는 책에서 무슨 말을 하는지 와닿지 않았다. 지금도 완벽하게 이해했다고 말을 하기 어렵다. 그래도 반복해서 읽다 보니 무엇을 말하고자 하는지 조금은 알 것 같다. 스터디 이후에도 다시 한 번 꼭 읽어봐야하는 챕터라고 생각한다.
  • 처음부터 완벽한 설계는 할 수 없다. 따라서, 책에서 말하는 것 처럼 아주 단순하면서도 관심사를 분리한 아키텍처로 소프트웨어 프로젝트를 진행하면서 조금씩 확장하는게 좋다고 생각한다. 물론, 일반적인 범위, 목표, 일정은 물론이고 결과로 내놓을 시스템의 일반적인 구조는 생각해야 한다.

시스템 제작과 시스템 사용을 분리하라

  • 제작은 사용과 아주 다르다. 제작과 사용은 뭐가 다르지? 라는 생각이 들자마자 호텔 공사 전, 후 예시를 통해서 깔끔하게 이해하였다. 소프트웨어 관점에서는 준비 과정(객체 제작, 의존성 연결)과 런타임 조직을 분리해야 한다.
  • 설정 논리는 일반 실행 논리와 분리해야 모듈성이 높아진다.
    • 분리하지 않을 경우 복잡한 테스트 코드, SRP 원칙 위반을 유발할 수 있다.
  • 시작 단계는 모든 애플리케이션이 풀어야 할 관심사다. 관심사 분리는 가장 오래되고 가장 중요한 설계 기법 중 하나다.

main 분리

  • 생성과 관련된 코드는 모두 main 혹은 main이 호출하는 모듈로 옮기고, 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정한다.
  • 애플리케이션은 그저 객체를 사용하기만 한다. 객체가 생성되는 과정을 전혀 모른다.

팩토리

  • 객체가 생성되는 시점을 애플리케이션이 결정할 필요도 생긴다. 그래도 객체가 생성되는 과정을 모르는 것은 동일하다.
  • ABSTRACT FACTORY : 구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 패턴

의존성 주입

  • 사용과 제작을 분리하는 강력한 메커니즘이다.
  • 의존성 주입은 제어 역전 기법을 의존성 관리에 적용한 메커니즘이다.
    • 제어 역전 : 한 객체가 맡은 보조 책임을 새로운 객체에게 전적으로 넘긴다. 새로운 객체는 넘겨받은 책임만 맡으므로 단일 책임 원칙을 지키게 된다.
  • 초기 설정은 시스템 전체에 필요하므로 대개 책임질 메커니즘으로 'main' 루틴이나 특수 컨테이너를 사용한다.
  • _객체는 의존성 자체를 인스턴스로 만드는 책임은 지지 않는다는 무슨 말일까?

확장

  • 처음부터 올바르게 시스템을 만들 수 있다는 믿음은 미신이다. 대신에 오늘 주어진 사용자 스토리에 맞춰 시스템을 구현하면 된다. 내일은 새로운 스토리에 맞춰 시스템을 조정하고 확장하면 된다. 이것이 반복적이고 점진적인 애자일 방식의 핵심이다.
  • 시스템 아키텍처는 사전 계획이 필요하지 않을까? 단순한 아키텍처를 복잡한 아키텍처로 조금씩 키울 수 없다는 현실은 정확하다. 하지만, 관심사를 적절히 분리해 관리한다면 소프트웨어 아키텍처는 점진적으로 발전할 수 있다. 관심사 분리가 점점 미신처럼 느껴진다,,
  • 관심사 분리
    • 잘못된 분리 : 덩치 큰 컨테이너와 밀접하게 결합
    • 영속성도 하나의 관심사다. 영속성, 정합성은 관심사보다 큰 개념이라고 생각했었다.

프록시

  • 코드 양과 크기는 프록시의 두 가지 단점이다.
  • 프록시를 사용하면 깨끗한 코드를 작성하기 어렵다.

테스트 주도 시스템 아키텍처 구축

  • 코드 수준에서 아키텍처 관심사를 분리할 수 있다면, 진정한 테스트 주도 아키텍처 구축이 가능해진다.
  • 그때그때 새로운 기술을 채택해 단순한 아키텍처를 복잡한 아키텍처로 키워갈 수도 있다.

명백한 가치가 있을 때 표준을 현명하게 사용하라

  • 표준이라는 이유만으로 사용하지 말자
  • 표준에 집착하면 고객 가치가 뒷전으로 밀려날 수 있다.

@qrlagusdn

Ch11. System

  • 자바를 사용하지 않아서 그런지 아니면 설계를 잘 몰라서 그런지 쉽게 이해하기 어려운 챕터였음

  • 적절한 추상화와 모듈화 매우 중요

시스템 제작(construction)과 시스템 사용(use)를 분리하라

  • 관심사 분리

  • Main 분리

    • 생성과 관련된 코드는 모두 main or main이 호출하는 모듈로 옮김
    • 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정

  • 팩토리 패턴

    • 팩토리 interface를 구현해서 한 종류의 객체를 만드는 것

    • 다음 챕터에서 나오는 템플릿 메소드 패턴과 유사?

      image

  • 의존성 주입

    • 하나의 객체가 다른 객체의 의존성을 제공하는 테크닉
    • 스프링
      • 객체 간의 의존성(객체 간의 관례)을 객체 내부에서 직접 해주는 대신, 외부에서 객체를 생성해서 넣어주는 방식

    image

확장

  • EJB
  • AOP
    • 어떤 로직을 기준으로 핵심적인 관점, 부가적인 관점으로 나누어서 보고 그 관점을 기준으로 각각 모듈화하겠다는 것
    • aspect 모듈화하고 핵심적인 비즈니스 로직에서 분리해서 재사용하게다는 것이 AOP의 취지
  • POJO

TDD 구축

의사 결정 최적화

  • 가능한 마지막 순간까지 결정을 미루는 방법

도메인 특화 언어?

회의록

  • 폴더 관리

    • 프로젝트 루트 경로에 회의록 폴더(summary) 라고 만들고, 그 밑에 주마다 논의했던 내용을 작성해서 올린다. (서로 공유한 내용, 회의록 포함)
    • repo에 내용을 올릴 때는 main에 바로 push 한다. (따로 branch, PR 관리 X)

  • issue 탭 사용

    • 구글밋 전에 한 주동안 스터디했던 장을 개인적으로 간단하게 정리해서 issue 탭에 올린다. (공유하고 싶은 내용이나 자료를 포함해도 괜찮다)
    • issue 탭에 올릴 때 타이틀은 [Ch1] 챕터 제목 이름 의 형태로 올린다.
    • 구글밋에서 각자 생각을 공유할 때 issue 탭에 작성한 것을 참고용으로 활용하면 좋겠다.