[keyword] 10장 - 유연한 설계
Closed this issue · 4 comments
Intention-Revealing Interface (의도를 드러내는 인터페이스)
도메인의 공개 인터페이스에서는 관계와 규칙을 시행하는 방법이 아닌 관계와 규칙 그 자체만을 명시한다. 이벤트와 액션을 수행하는 방법이 아닌 이벤트와 액션 그 자체만을 기술한다. 방정식을 푸는 방법을 제시하지 말고 이를 공식으로 표현한다. 문제를 내라. 하지만 문제를 푸는 방법을 표현해서는 안 된다. (p.262)
Side-Effect-Free Function (부수효과가 없는 함수)
부수효과라는 용어를 사용하는 것은 이처럼 의도하지 않은 영향력을 발생시키는 상호작용이 불가피하다는 점을 강조하는 것이다. (p.266)
함수는 여러 번 호출해도 무방하며 매번 동일한 값을 반환한다. 함수는 중첩된 깊이에 대해 걱정하지 않고도 다른 함수를 호출할 수 있다. 함수는 부수효과를 지닌 연산에 비해 테스트하기 쉽다. (p.266)
Q. 여기서 말하는 함수란 메서드를 포함하는 것일까?
Assertion (단언)
문제는 사후조건에 기술된 특성이 개발자들이 페인트 혼합에 관해 사고하는 개념과 일치하지 않아 실수를 저지르게 된다는 점이다. (p.274)
Conceptual Contour (개념적 윤곽)
add()를 두 개의 개별적인 단계로 나눠서는 안 된다. 동일한 연산 내에서 현재 다루고 있는 "합"의 의미를 넘는 수준까지 처리하려고 해서는 안된다. (p.278)
도메인을 중요 영역을 나누는 것과 관련한 직관을 감안해서 설계 요소(연산, 인터페이스, 클래스, AGGREGATE)를 응집력 있는 단위로 분해하라. 계속적인 리팩터링을 토대로 변경되는 부분과 변경되지 않는 부분을 나누는 중심 축을 식별하고, 변경을 분리하기 위한 패턴을 명확하게 표현하는 CONCEPTUAL CONTOUR를 찾아라. (p.278)
Standalone Class (독립형 클래스)
이를테면, 자바 언어에서는 숫자, 문자열, 컬렉션과 같은 기본 요소를 원시 타입과 표준 라이브러리에서 제공한다. 하지만 이런 기본 요소를 제외한 객체를 이해하기 위해 기억해야 하는 그 밖의 모든 부가적인 개념은 정신적 과부하를 초래한다. (p.284)
Assertion(단언) 파트의 273쪽에서
'예측 가능성'이라는 단어와
'자동화된 단위 테스트를 작성해서 ASSERTION의 내용을 표현하라'는 내용이 와닿았습니다
- 검증의 수준을 어디까지 해야하는가
- ex. 회원가입 : 카운팅 / 객체 일부 주요 필드만 / 객체 전체 필드
- 무엇이 중요한지에 따라 달라짐 : 메소드가 몇 번 호출됐는지, 객체의 상태가 중요한지 등등
- 호출 순서도 고려하는 경우? : 순서에 맞는 mocking
- ZIO (스칼라 진영) : 읽기가 쉽다? 의존성 주입 용이
- 테스트에서 수행하고자 하는 최종 상태를 무엇으로 정의할것인지 결정하는 것도
선언적인 설계
286쪽부터 310쪽까지 쭉 선언적인 형식의 중요성을 SPECIFICATION과 연관지어 설명하고 있다는 느낌을 받았습니다.
다만 너무 선언적이고 구체적인 형식에 얽매여 하위 객체 또는 연산을 꼭 여러 개 만들 필요가 없다고 해주었습니다.
필요한 연산이 오직 AND뿐이라면 AND만 구현하는 방안을 주저하지 말자. (p. 296)
그리고 책에서는 shares math 예제, 포섭 관계를 설명함으로써 여러 specification을 조합할 때의 장점을 소개하고 있습니다.
다만 읽다보니 클래스가 너무 많아져 복잡성이 증가하지 않을까 싶어 chatgpt한테 이러한 의문을 제시해보았습니다.
이렇다고 합니다.
이어서 실제 예시를 보고 싶어서 선언적인 형식의 SPECIFICATION을 잘 다루고 설명해주는 회사 기술블로그 포스팅을 소개해달라고 해보았습니다. 그런데 전부 404 not found가 뜨는 링크를 보내주더라고요... 예시가 있으면 좋을텐데 말이죠.
DSL
이러한 언어를 사용하면 프로그램의 표현력을 월등히 향상시킬 수 있고 UBIQUITOUS LANGUAGE와도 가장 높은 일관성을 유지할 수 있다. (p. 291)
선언적인 형식으로 DSL을 이용하여 표현하는 것을 권장하고 있습니다.
도메인 특화 언어에 해당되는 하위 도메인을 만들어 책임을 위임할 수도 있다고 생각이 드네요. (ex. 자동차, 커피와 같은 사물이 아닌, 거래, 점수갱신과 같은 도메인 생성)