9장 암시적인 개념을 명확하게

[youngvly]

09. 암시적인 개념을 정확하게

개념 파헤치기

1. 도메인 전문가가 사용하는 언어에 귀 기울여라
2. 설계에서 가장 어색한 부분을 조사하라.
   • 새로운 요구사항으로 복잡성이 증가되는 부분
3. 모순점에 대해 깊이 고민하라
   • 도메인을 잘못이해하거나, 용어를 다르게 쓰는 부분.
4. 서적 참고
   • 도메인에 관련된 전문서적
   • 해당 도메인을 경험한 다른 sw전문가의 서적
5. 시도하고 또시도하라..

다소 불명확한 개념을 모델링 하는 법

1. 명시적인 제약조건
   • 제약조건을 자체적인 메서드로 분리하면 제약조건이름이 생겼기 때문에 명확하게 표현가능.
   • 어떤 제약조건을 포함한 객체의 설계가 잘못되어있음을 나타내는 조짐
     1. 제약조건을 평가하려면 객체의 정의에 적합하지않은 데이터가 필요하다.
     2. 관련된 규칙이 여러 객체에 걸쳐 나타나고, 다른 계층구조의 객체간의 중복또는 상속관계를 강요한다.
     3. 논의는 제약조건에 초점이 맞춰지지만, 구현은 절차적인 코드에 묻혀 명시적으로 표현되지 않는다.
2. 도메인 객체로서의 프로세스
   • 객체는 절차를 캡슐화해서 절차대신 객체의 목표나 의도에 관해 생각하게 해야한다.
   • 프로세스를 수행하는 방법이 한가지 이상일때, 알고리즘 자체 또는 일부를 객체로만드는 방법이 있다.

Specification

: 규칙을 표현하는 수단, 조건로직으로부터 규칙을 분리해서 규칙이 모델 내에서 만들어지게끔 만든다.

• 규칙을 도메인 계층에 유지할 수 있다.

  specification 의 용도

  1. 검증
• 어떤 객체가 특정한 기준을 만족하는지 판단하는 predicate(술어)이다
  2. 선택 (또는 질의)
     • 컬렉션 내의 특정 객체를 선택
     • ❓ repository의 선택기준으로 사용된다면,이 specification의 위치는 domain인가 infra인가? Sql도 가지고있는데.. / repository를 vo객체안으로 가져와버린다고..? 괜찮은건가,,? (p.248)
  3. 생성 (요청 구축)
     • generator(생성기 -> ❓팩토리인가?) 로 작성시 객체 생성 절차나 일련의 명령이 포함되어 generator의 행위를 암시적으로 규정할수밖에없다.
     • specification으로 인터페이스 정의할때 장점
       1. 결과물에 대한 요구사항은 선언하지만, 결과물을 생성하는 방법은 정의하지 않는다.
       2. 생성규칙을 명시적으로 전달 가능.
       3. 테스트하기 수월.
     • 특정 요구사항을 만족하는 새로운 객체의 생성을 명시.
     • 예제가 생성보다는,, 선택에 가까운듯하다..❔(p.255)

       If(container.canAccommodate(drum){
       Return container;
       }

[y2o2u2n]

• 도메인 전문가가 사용하는 언어에 귀 기울여라
• 설명하기 힘들 만큼 복잡한 부분, 새로운 요구사항 탓에 복잡성이 증가하는 등의 설계에서 어색한 부분을 조사해라
• 해당 도메인의 서적을 참고하라
• 시도하고 또 시도하라

다소 불명확한 개념을 모델링하는 법

• 명사와 동사로 표현되지 않는 다른 중요한 범주의 개념도 존재할 수 있음
• 3 가지
  • 제약 조건 : 제약 조건을 담는 메서드 분리한다. 이 방법만으로 객체 지향적 설계가 되지 않으면 객체로 분리할 수도 있음
  • 프로세스 : 프로세스를 수행하는 방법이 한 가지 이상일 때 해당 알고리즘을 하나의 객체로 만드는 STRATEGY 를 사용
  • SPECIFICATION

SPECIFICATION

• ENTITY 나 VALUE OBJECT 가 맡는 책임에 맞지 않고 도메인 객체의 기본 의미를 압도할 때 도입
• 다른 객체에 대한 제약조건을 Boolean 결과로 내는 특별한 객체를 만드는데 이것이 SPECIFICATION
• 3 가지
  • 검증 : 객체가 어떤 요건을 충족시키거나 특정 목적으로 사용할 수 있는지 검증
  • 선택(또는 질의) : 컬렉션 내의 객체를 선택. 일반적으로는 메모리 내에 없으므로 REPOSITORY 를 활용
  • 요청 구축(생성) : 특정한 요구사항을 만족하는 새로운 객체의 생성을 명시

[chanhyeong]

implicit -> explicit

🤔 숨은 스펙 찾기?

개념 파헤치기

암시적인 개념을 드러내는 단서에 초점

• 팀에서 사용하는 언어, 부자연스러운 + 모순되는 전문가의 견해, 도메인과 관련된 문서 조사

언어를 잘 들어라

어색한 부분을 조사

• 누락된게 있는지, 책임이 어색한지
• 누락된걸 알아도 어떻게 할지 모를 때는 -> 도메인 전문가에게 토스

모순에 대한 고민

• 모순을 찾는 과정에서 도메인의 심층적인 통찰력에 이를 수 있다
• 모든 모순을 해소하는건 불가능, 바람직하지도 않음 (14장에 나올 예정)
  • 모순을 유지할 때, 상반된 주장을 모두 적용하는 과정 간에 숨겨진 사실이 나올 수 있다

도메인 관련 서적 읽기

계속 시도

불명확한 개념 모델링

Explicit Constraints

제약 조건을 별도의 메소드로 분리

Processes as Domain Objects (도메인 객체로써의 프로세스)

• 모델 내에 프로세스를 포현해야 하는데
• 프로세스가 나타나면 객체를 어색하게 설계하게 됨
• 알고리즘 자체 or 일부를 하나의 객체로 생성
  • 어떤 프로세스를 선택하는가 = 어떤 객체를 선택하는가
  • 각 객체는 STRATEGY 를 표현

SPECIFICATION

기존 logic-programming 에서 사용하던 predicate 를 갖는 특별한 객체 생성
-> 테스트 메소드가 독립적인 객체로 발전

• 다른 객체에 대한 제약조건을 기술하는 객체, Value Object
• 생명주기: 생성 -> 테스트 -> 제거
• Invoice 예시에서는 평가 일자를 specification 안에 명시
• specification 을 이용하여 규칙을 domain layer 에 유지

적용과 구현

1. Validation: 특정 조건에 부합하는지 판단하기 위해 개별 객체를 테스트
2. Selection: 특정한 조건을 기반으로 객체 컬렉션 일부 선택
   1. RDB 쿼리문 생성 (asSQL())
      • 테이블 구조가 domain layer 에 노출되는 문제
   2. Repository 에 특정 쿼리를 갖는 메소드를 이름으로 명시. Specification 에서 Repository 를 받아서 실행
      • 규칙을 Specification 에 모으지는 못했지만, 본질적인 규칙은 모아져 있음
   3. 일단 조건에 맞는걸 다 들고와서 Specification 메소드 수행
      • 메모리 성능 저하
3. Building to order (Generating) (요청구축) ❓ : 아직 존재하지 않는 객체에 대한 기준 명시. 조건을 만족하는 객체 or 객체 집합 생성하거나 재구성
   • Generator ❓ 구현을 인터페이스로부터 분리
     • 생성할 결과물에 대한 요구사항 선언. 결과물을 생성하는 방법은 정의하지 않음
   • 생성 규칙을 명시적으로 전달 -> 세부 이해 없이 결과물 예상 가능
   • Specification 에 포함된 조건에 따라 객체 생성하여 더 유연한 인터페이스 및 개선 가능
   • Generator 에 대한 입력을 정의하는 방법이 모델에 포함되어 있어 테스트가 수월

WarehousePacker 에시는 Specification 이 맞는지? Generator 는 또 뭐지?

[bearics]

❓p223, 5. 예약 보고서로부터 도메인 로직을 제거하고 별도의 도메인 계층으로 옮김.

• 운항 일정은 이전에는 모델이 아니였다하는데, 그러면 뭐로 있던거지?
• 예약 보고서로부터 도메인 로직 == 응용 단에서 Cargo랑 Itinerary를 조인해서 가져오기, 이부분을 말하는건가?

❓ specification의 위치는? domain, infra 어디..?