일반적인 웹 어플리케이션 개발할 때 유용한 방법을 알아보기 위한 가이드북

• 객체의 두 종류

  1. 작업을 수행하거나 정보를 반환하는 서비스 객체. EX) Spring Service
  2. 데이터를 담고 있으며, 데이터를 조작하거나 가져오는 행위를 선택적으로 드러내는 객체 EX): Domain

• 서비스 객체

  1. 한번 생성하면 특정 작업을 반복적으로 실행 할 수 있는 객체
  2. 주로 Controller, service, renderer 등 행위를 나타내는 이름을 가진다
  3. 가이드
     1. 의존성과 설정 값은 생성자의 인자로 주입한다
     2. 짝이 있는 설정 값은 함께 두는 클래스를 이용하여 주입한다
     3. 필요한 것의 위치가 아닌 그 자체를 주입한다 → 불필요한 정보 주입 방지
     4. 모든 생성자 인자는 필수값이어야 한다
     5. 선택적 의존성이 필요하다면 차라리 더미를 주입하라
     6. 아래의 경우 정적 의존성을 객체 의존성으로 변경하라
        1. 의존한 객체의 행위를 대체하거나 개선해야 하는 경우
        2. 의존 객체의 행위가 복잡해서 몇 줄로는 같은 효과가 없는 경우
        3. 해당 함수를 기본 타입 값 대신 객체로 처리가 가능한 경우
     7. 작업에 관련된 데이터는 생성자 인자가 아니라 메서드 인자로 전달한다.
        1. 서비스를 다시 인스턴스화 하지 않고 작업을 할 수 없다면 메서드의 인자가 맞다

• 값 / 모델 객체

  1. 데이터를 담고 있으며, 데이터를 조작하거나 가져오는 행위를 선택적으로 드러내는 객체
  2. 생성 시점에 필요한 최소의 데이터를 제공하고 유효성을 검사해야 하는 객체
  3. 서비스 객체의 행위가 필요하면 메서드의 인자로 주입해야 한다
  4. 값 객체
     1. string, int와 같은 기본 타입을 감싸는 특정 도메인의 값을 표현할 때 쓰인다
     2. 생성되면 불변이며, 데이터가 변경되면 새로운 객체를 반환하는 것이 좋다
     3. 교체 가능하고 익명이다
  5. 모델(개체) 객체
     1. 응용 프로그램의 핵심 객체
     2. 반드시 유일한 식별자가 부여된다
     3. 데이터의 조작, 조회의 일부를 표현하는 객체
     4. 주로 가변 객체이다
     5. 데이터가 변경되더라도 항상 유효한 객체여야 한다
  6. 데이터전송(DTO) 객체
     1. 외부 ↔︎ 내부 프로그램으로 변환하기 위한 데이터를 가진 객체
     2. 속성을 하나하나 설정 가능하나 단 한번만 가능하도록 유도해야 한다
     3. 모든 속성을 노출한다
     4. 일반적인 생성자로 생성 가능하다

• 변경 가능한 객체에는 fluent(흐름식) 인터페이스를 구현하지 말자

  • 이는 사용자에게 변경된 객체인지 복사된 객체인지 헷갈리게 만든다

• 메서드

  • 구현 기본 템플릿
    • [유효한 반환형] function 이름 (args) { [ 사전 조건 확인] [ 실패 시나리오 ] [ 성공 ] [ 사후 조건 확인] [ 반환 ] }
    • 사전조건: 주로 단언문 또는 if를 이용하여 주어진 조건이 정상인지 확인한다
    • 실패 시나리오: 외부 조건에 의해 실패하는 경우의 에러 처리
    • 사후 조건 확인: 요즘엔 주로 사용되지 않으며 테스트 코드로 대처한다
    • 반환: 최대한 빨리 반환해야 한다는 사실만 기억하라
  • 질의 메서드
    • 객체에서 특정한 조건에 해당하는 정보를 반환하는 메서드
    • 메서드의 이름으로 불확실성을 보여줘야 한다( EX: getXXX → not nullable , findXXXX → nullable )
    • 응용 프로그램이 시스템 경계를 넘는 경우 추상화를 준비해야 한다
    • 명령 메서드(하기 기술)는 호출되어서는 안된다
    • 테스트는 더미와 스텁을 이용한다
  • 명령 메서드
    • 객체를 사용하여 특정 작업( 메일전송, 데이터베이스 저장) 등을 하는 메서드
    • 주로 Void, Unit 형태의 Return형을 사용해야 한다
    • 명령 메서드의 유효 범위 판단 조건
      • 메서드 이름에 And가 붙어야 정확히 표현이 되는가?
      • 메서드 작업의 일부를 백그라운드로 실행해야 하는가?
      • 모든 코드 내용이 주 작업에 기여하는가?
    • 질의 메서드의 호출은 얼마든지 가능하다
    • 시스템의 경계를 넘는 명령에는 추상화를 이용한다.
      • 단 단순화 할 수 있는 사례가 3개 이상인 경우에만 하려고 노력한다
    • 테스트는 목과 스파이를 이용한다

• 책임의 분리

  • 역(inverse) 연산을 구현하는 것은 지극히 자연스럽다 그러나 모델(entity)에서는 쓰기와 읽기 모델을 분리하는 것이 좋다 → 권한이 없는 클라이언트에게 전달되지 않게 만들 수 있다
  • 개체를 통해 정보만 가져오는 클라이언트에게 쓰기 권한을 주지 않는 것이 핵심이다
  • 객체 내부에서 해결 할 수 있는 일을 밖으로 끄집어 내지 마라

• 서비스의 행위 변경의 방법

  • 클래스의 메서드 로직을 변경하는 방법 → 비용이 들며 망가질 위험이 존재
  • 객체 그래프의 구조를 변경 → 망가질 위험이 하위 클래스 일부로 전이됨
  • 생성자를 변경하여 행위를 교체할 수 있도록 해야 한다
  • 추가 행위에 대해 도메인 이벤트를 발생시키는 것을 고민하자 → 많은 의존성을 제거 할 수 있다
  • 특질(trait)
    • 코드를 재 사용하기 위한 방법
    • 일반적으로 구성(composition)을 이용하자
    • 코틀린에서는 default method interface를 이용하여 구현 가능하다

• 실제 개발 구성 가이드

• 제어기 ( controller )
• 사용자가 제공한 인자를 바탕으로 서비스 객체, 읽기 모델을 실행한다
• 특정 전달 매커니즘에 기반하므로 infrasturcture(기반) 코드 로 간주해야 한다
• 받은 입력을 검사한다
• 응용 프로그램 서비스
• 쓰기 모델 저장소
• 모델(개체) = 도메인
• 값 객체
• 이벤트 수신자
• 읽기 모델 저장소