우키의 개발 블로그

도메인 주도 설계 - 11. 분석 패턴의 적용

wookkl — Thu, 23 May 2024 09:55:37 +0900

본 내용은 에릭 에반스의 도메인 주도 설계를 공부하면서 제 나름대로 이해하기 쉽게 정리한 글입니다.

이해가 어려우시다면 댓글 부탁드립니다.

도메인 문제들을 관찰하면서 익숙한 책임이나 관계들이 발견되는데 이러한 익숙한 것들은 패턴 형식으로 기록되어 문제를 해결하는데 도움을 준다. 경험으로 축적되어 기록된 패턴을 사용하는 방식이 분석 패턴의 적용이다. 이 패턴은 특정 개념을 표현하는 객체를 사용해서 더 높은 수준에서 특화된 영역을 다룬다. 곧바로 사용할 수있는 해결책은 아니고 특정 도메인의 모델을 개발할 떄 유용한 지심서에 해당한다.

최상의 분석패턴은 과거의 프로젝트에서 유용한 경험을 전달하고 모델에 대한 통찰력을 제공한다.

도메인 주도 설계 - 10. 유연한 설계

wookkl — Fri, 10 May 2024 10:50:13 +0900

본 내용은 에릭 에반스의 도메인 주도 설계를 공부하면서 제 나름대로 이해하기 쉽게 정리한 글입니다.

이해가 어려우시다면 댓글 부탁드립니다.

INTENTION-REVEALING INTERFACE(의도를 드러내는 인터페이스)

객체를 효과적으로 사용하는데 알아야할 정보를 구현 로직의 이해 필요없이 인터페이스로만 얻을 수 있게 설계한 인터페이스를 뜻한다. 컴포넌트의 구현 세부사항을 고려해야 한다면 캡슐의 가치는 사라진다. 설계에 포함된 모든 공개 요소가 조화를 이뤄 인터페이스를 구성하고 각 요소의 이름을 토대로 설계 의도를 드러낼수 있어야 한다.

오직 결과와 목적만을 표현하도록 클래스의 연산의 이름을 부여해야 한다. 이렇게하면 클라이언트 개발자가 내부를 이해할 필요성이 줄어든다. 그 의미를 쉽게 추측하기 위해 UBIQUITOUS LANGUAGE에 포함된 용어를 따라하 한다.

SIDE-EFFECT-FREE FUNCTION(부수효과가 없는 함수)

여기서 SIDE-EFFECT(부수효과)라는 의미는 의도하지 않은 시스템의 상태에 대한 영향력을 의미한다. SIDE-EFFECT-FREE FUNCTION는 위의 의미대로 부수효과가 없는 함수이다.

다수의 규칙에 따라 상호작용하거나 여러 가지 계산을 조합하면 예측하기가 어려워지고 연산을 호출하는 개발자가 결과를 예상하려면 연산 자체 뿐만 아니라 연산이 호출하는 다른 연산의 구현도 이해해야 한다. 이렇게 안전하게 예측할 수 없다면 개발자가 연산을 조합해서 사용하는 데 제약이 따르고 행위가 풍부해지지 않는다.

함수에 부수 효과를 없애는 두 가지 방법

명령과 질의를 엄격하게 분리된 다른 연산으로 분리한다. 변경을 발생시키는 메서드는 도메인 데이터를 반환하지 않고 가능한 한 단순하게 유지한다.
연산의 결과를 표현하는 새로운 VALUE OBJECT를 생성하서 반환한다. 생명주기를 신중하게 통제해야 하는 ENTITY와 달리 VALUE OBJECT는 그럴 필요가 없다

ASSERTION(단언)

ASSERTION은 SIDE-EFFECT-FREE FUNCTION으로 분리 후에도 ENTITY에 남아있는 부수효과를 초래하는 명령을 명확하고 다루기 쉽게 설계하는 방식이다. 연산의 부수효과가 구현에 의해서만 함축적으로 정의되는 혼란스러운 부분을 해결하고 프로그램을 이해하려면 분기 경로를 따라 실행 경로를 추적해야하는 복잡함을 해결한다.

ASSERTION을 설계하는 방법은 연산의 사후조건과 클래스 및 AGGREGATE에 불변식을 명시한다. 프로그래밍 언어를 사용해서 ASSERTION을 명시할 수 없다면 자동화된 단위 테스트를 작성해서 ASSERTION의 내용을 표현한다.

CONCEPTUAL CONTOUR(개념적 윤곽)

유연하게 조합하기 위해 작은 크기로 나눌떄가 있고 복잡성을 캡슐화하기 위해 기능을 더 큰 단위로 통합할 때가 있는데 그 기준을 도메인 의미 수준으로 명확하게 설계하는 방식이다. "합(addition)"이 도메인에서 의미를 가진다면 그 수준에서 메서드를 구현한다. 딱 도메인 의미 단위 수준에서 메서드를 구현해야 한다. 합을 더이상 나누거나 의미를 넘는 수준까지 처리하려고 하면 안된다.

도메인을 중요 영역을 나누는 것과 관련한 직관을 감안해서 설계요소를 응집력 있는 단위로 분해해야 한다. 계속적인 리팩터링을 토대로 변경되는 부분과 변경되지 않는 부분을 나누는 축을 식별하고 변경되는 부분을 분리하기 위한 패턴을 명확하게 표현하는 CONCEPTUAL CONTOUR을 찾아야 한다.

STANDALONE CLASS(독립형 클래스)

STANDALONE CLASS란 클래스의 결합도를 낮춰서 현재 클래스의 도메인 개념과 상관없는 것들을 없애는 설계 방식이다.

객체의 설계의 기본원리중 하나인 낮은 결합도를 갖추고자 노력해야 한다. 현재 도메인과 무관한 모든 개념을 제거해서 클래스가 완전히 독립적(self-ccontained)로 바뀌고 단독적으로 이해할 수 있다. 독립적인 클래스는 MODULE을 이해하는데 따르는 부담을 상당히 덜어준다. 낮은 결합도는 개념적 과부화를 줄여준다.

CLOSURE OF OPERATION(연산의 닫힘)

CLOSURE OF OPERATION는 반환 타입과 인자 타입이 동일하게 연산을 정의하는 설계 방식이다. 닫힌 연산은 부차적인 개념을 사용하지 않고도 고수준의 인터페이스를 제공한다. 이 패턴은 VALUE OBJECT의 연산을 정의하는 데 주로 사용된다. 연산시 VO를 인자로 받고 새로운 VO를 반환한다. ENTITY는 생명주기가 매우 중요하므로 연산의 결과로 새로운 ENTITY를 반환하는 경우는 잘 없다.

도메인 주도 설계 - 9. 암시적인 개념을 명확하게

wookkl — Thu, 2 May 2024 09:35:22 +0900

본 내용은 에릭 에반스의 도메인 주도 설계를 공부하면서 제 나름대로 이해하기 쉽게 정리한 글입니다.

이해가 어려우시다면 댓글 부탁드립니다.

개발자들이 토의 중에 단서를 얻거나 설계상 암시적으로 존재하는 개념을 인지하면 도메인 모델과 관련 코드를 대량으로 바꾸게 된다. 하나 이상의 객체와 객체간 관계를 활용해 모델 내에 해당 개념이 명확하게 표현된다. 암시적 개념을 명확한 개념으로 변환하는 작업 역시 심층 모

델로의 도약에 해당된다.

개념 파헤치기

언어에 귀 기울여라

도메인 전문가가 사용하는 언어에 귀 기울여야 한다. 복잡하게 얽힌 개념들을 간결하게 표현하는 용어가 있거나 개발자가 사용하는 단어를 적절하게 고쳐주는 등이 모델에 기여하는 개념의 실마리가 된다. 하지만 이것이 "명사는 객체다" 라는 개념을 표현하는 것은 아니다. 사용자, 도메인 전문가, 개발자가 설계상 어디에도 표현돼 있지 않은 어휘를 사용하고 있다면 누락된 어휘를 설계에 포함시켜야 한다. 모델과 설계를 향상시킬 수 있는 기회이다.

어색한 부분을 조사하라

필요한 개념이 대화나 문서로 인식할 수 있을만큼 드러나 있지 않을 때도 있다. 이미 존재하는 개념을 파헤치거나 새로운 개념을 만들어야 할지도 모른다. 설명하기 힘들 만큼 복잡한 작업을 수행하는 프로시저와 관련된 부분이나 새로운 요구사항에 복잡성이 증가하는 부분에 어색한 부분이 없는지 조사해야한다.

모순점에 대해 깊이 고민하라

도메인 전문가들은 자신의 경험과 필요에 따라 각기 다른 방식으로 사물을 바라본다. 도메인 전문가도 도메인 분석 과정을 거치고 논리적으로 모순되는정보를 제공하기도 한다. 이와 같은 모순은 더 심층적인 모델에 이르는 중요한 단서로 활용될 수 있다. 용어를 다르게 쓰거나 도메인을 잘못 이해하면서 모순이 발생한다. 이러한 모순들을 조화 시킬 수만 있다면 심오한 뭔가를 밝혀낼 수 있을지도 모른다.

도메인 서적을 참고하라

다양한 분야에 대해 근본 개념과 일반적인 통념을 설명하는 책을 참고하면 일관성 있고 사려 깊은 관점에서 작업을 시작할 수 있다.

시도하고 또 시도하라

선택의 여지는 없다. 시도하고 또 시도하면서 유용한 것이 무엇이고 유용하지 않은 것이 무엇인지 배워가야 한다.

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

"명사와 동사"로 표현되지 않은 다른 중요한 범주의 개념도 모델 내에 명시적으로 표현할 수 있다.

SPECIFICATION(명세)

모든 종류의 애플리케이션에는 규칙을 검사하는 Boolean 메서드가 있다. 규칙이 단순하면 hasNexxt()나 isOverdue() 같은 규칙을 처리하면 된다. 하지만 이렇게 단순하기만 한 것은 아니다. 규칙을 검사하는 로직이 길어지면 도메인 로직이 규칙을 검사하는 로직에 의해 가려질 수 있다. 이를 위해 분리하는 과정이 필요하다.

업무 규칙이 ENTITY나 VALUE OBJECT가 맡고 있는 책임에 맞지 않고 규칙의 다양성과 조합이 도메인 객체의 기본 의미를 압도할 때가 있다. 이러한 업무 규칙들을 위해 술어와 유사한 명시적인 VALUE OBJECT인 SPECIFICATION을 만들면 된다. SPECIFICATION은 어떤 객체가 특정 기준을 만족하는지 판단하는 술어다.

도메인 주도 설계 - 8. 도약

wookkl — Fri, 26 Apr 2024 11:59:06 +0900

본 내용은 에릭 에반스의 도메인 주도 설계를 공부하면서 제 나름대로 이해하기 쉽게 정리한 글입니다.

이해가 어려우시다면 댓글 부탁드립니다.

심층 모델

기존 전통적인 방식의 객체 분석 방식은 요구사항 문서의 명사와 동사를 식별하고 명사는 초기 객체 이름, 동사는 메서드로 사용하는 것이다. 초보자를 가르치기에는 유용하지만, 실제 도메인 초기 모델은 얄팍한 지식에 기반을 둔 무의미한 모델인 경우가 대부분이다.

심층 모델(DEEP MODEL)이란 도메인의 피상적인 측면은 배제하고 도메인 전문가와 주요 관심사를 중심으로 도메인 지식을 알기 쉽게 표현한 것이다. 추상화를 의미하진 않는다.

발견 과정

해결해야 하는 문제에 적합한 설계(심층 모델)를 만들려면 먼저 도메인 중심 개념을 담고 있는 모델을 확보해야 한다. 이는 9장(암시적인 개념을 명시적으로)에서 적극적으로 도메인 중심 개념을 찾아 설계에 반영하는 방법을 다룬다.

모델과 설계 간의 관계가 밀접하므로 코드가 리팩터링하기 어려운 경우 더는 모델링을 진행할 수 없는데 10장(유연한 설계)에서는 소프트웨어를 쉽게 확장하고 변경할 수 있는 방법을 다룬다.

도약

리팩터링의 효과는 선형적으로 증가하지 않는다. 일반적으로 리팩터링에 들어간 노력의 양이 적다면 최소의 보답만 돌아온다. 리팩터링은 엔트로피와의 싸움이며 레거시 시스템이 퇴보하는 것을 막는다. 하지만 가장 중요한 통찰력은 어느순간 찾아오고 이는 프로젝트 전체에 퍼져나간다.

심층 모델은 한 번에 하나의 객체를 대상으로 하는 소규모 리팩터링 과정을 거처 서서히 모습을 드러낸다. 찾지 못했던 UBIQUITOUS LANGUAGE도 찾게 된다.

기본에 집중하라

도약은 일반적으로 수많은 적정 규모의 리팩터링을 수행하고 나타난다. 대부분의 시간은 단편적인 개선에 소요되고 결과적으로 연속적인 정제 과정 속에서 서서히 모델에 대한 통찰력을 얻게 된다.

도약이 등장하기 위해서는 지식 탐구와 함께 인내심을 가지고 UBIQUITOUS LANGUAGE를 만드는 일에 집중해야 한다.

도메인 주도 설계 - 6. 도메인 객체의 생명주기(AGGREGATE, FACTORY, REPOSITORY)

wookkl — Wed, 24 Apr 2024 09:44:45 +0900

본 내용은 에릭 에반스의 도메인 주도 설계를 공부하면서 제 나름대로 이해하기 쉽게 정리한 글입니다.

이해가 어려우시다면 댓글 부탁드립니다.

AGGREGATE(집합체)

AGGREGATE는 데이터 변경의 단위로 다루는 연관 객체의 묶음 개념이다. 복잡한 연관관계를 맺는 객체를 대상으로 일관성을 보장한다. 각 AGGREGATE에는 루트(root)와 경계(boundary)가 있고 루트는 단 하나만 존재하고 특정 ENTITY를 가리킨다. 경계안에 객체는 서로 참조 가능하다. 경계 바깥 객체(또 다른 AGGREGATE)는 루트만 참조 가능하다. 지역 식별성은 AGGREGATE내에서만 구분하면 된다.

예를 들어, 자동차는 전역 식별성을 가진 ENTITY이다. 네개의 바퀴는 식별할 수 있다면 지역 식별성을 가진다. 그러나 엔진부에 일련번호가 새겨져 있어서 자동차와는 무관하게 추적되기도 한다. 다른 애플리케이션에서는 엔진이 자체적인 AGGREGATE가 될 수도 있다.

AGGREGATE를 구현 하기 위한 모든 트랜잭션에 적용되는 규칙

루트 ENTITY는 전역 식별성을 가지고 불변식을 검사할 책임을 가짐
경계 안의 ENTITY는 지역 식별성을 지님 (AGGREGATE내에서만 유일)
AGGREGATE는 서로 루트만 참조 가능하고 내부 구성요소는 참조할 수 없음. 루트가 내부 ENTITY의 참조를 전달할 수는 있지만 일시적으로만 사용해야 함. VALUE OBJECT는 자유롭게 전달 가능
DB 질의시 AGGREGATE의 루트만 직접적으로 획득할 수 있음
삭제시 경계안의 모든 요소를 한 번에 제거해야 함

FACTORY(팩토리)

FACTORY는 전체 AGGREGATE를 생성하는 일이 복잡해서지거나 내부 구조를 너무 드러낼 경우에 캡슐화해주는 개념이다. 예를 들어 자동차 애플리케이션에서 자동차를 하나하나 특정 엔진, 특정 타이어 등을 조립해서 하나의 객체를 만들어서 사용될 것이다. 비지니스에서 자동차 객체를 사용하는 것에만 가치가 있지 조립해서 만드는 일은 그다지 중요한 일이 아니다. FACTORY는 이러한 복잡한 복합 객체를 조립하는 일을 담당한다

어떤 객체를 생성하는 것이 그 자체로도 주요한 연산이 될 수 있지만 복잡한 조립 연산은 생성된 객체의 책임으로 어울리지 않는다. 이런 책임을 클라이언트에 두면 이해하기 힘든 설계가 만들어 질 수 있다. 자신의 책임이 다른 객체를 생성하는 것인 요소를 FACTORY라 한다.

REPOSITORY(리파지터리)

데이터베이스로부터 도메인 모델 객체를 CRUD 시 AGGREGATE 루트로만 참조를 할 수 있도록 직접적인 참조를 캡슐화하는 개념이다. 모든 객체 저장과 접근은 REPOSITORY가 책임을 가지고 클라이언트는 모델에 집중할 수 있도록 한다. 모든 REPOSITORY는 클라이언트가 특정 기준에 부합하는 객체를 요청할 수 있는 메서드를 제공한다. REPOSITORY는 클라이언트가 진 큰 부담을 덜어주고 클라이언트는 단순한 의도를 드러내는 인터페이스로 소통한다.

REPOSITORY의 장점

DB에 있는 데이터를 객체로 가져오고 해당 객체의 생명주기를 관리하기 위한 모델을 클라이언트에게 제시
영속화 기술과 다수의 데이터베이스 전략으로부터 애플리케이션과 도메인 설계를 분리한다
객체 접근에 대한 설계를 결정
테스트시 가짜 구현으로 대체할 수 있음

명심해야할 중요한 사항

타입을 추상화: REPOSITORY가 반환하는 객체 타입을 추상화할 수도 있음(TradeOrder로 추상화하면 SellOrder나 BuyOrder가 될 수도 있음)
클라이언트와의 분리를 활용: 이렇게 하면 클라이언트에서 직접 질의할 때보다 더 자유롭게 REPOSITORY의 구현을 변경할 수 있고 영속화 전략을 바꿔가면서 캐싱 등 최적화를 수행할 수 있음
클라이언트가 트랜잭션 커밋 제어: 데이터베이스에 대한 삽입과 삭제를 REPOSITORY가 수행하지만 아무것도 커밋하지 않음. 클라이언트가 올바르게 단위작업을하고 커밋할 수 있도록하면 트랜잭션 관리가 더 단순해짐

도메인 주도 설계 - 5. 소프트웨어에서 표현되는 모델(ENTITY, VO, ...)

wookkl — Fri, 19 Apr 2024 09:51:36 +0900

본 내용은 에릭 에반스의 도메인 주도 설계를 공부하면서 제 나름대로 이해하기 쉽게 정리한 글입니다.

이해가 어려우시다면 댓글 부탁드립니다.

ENTITY(엔티티, 참조객체)

어떤 객체를 일차적으로 해당 객체의 식별성으로 정의되는 것으로 ENTITY의 생명주기 동안에 내용이나 속성이 바뀌어도 연속성이 유지되는 것을 말한다. ENTITY에 포함된 속성보다는 정체성(식별성)에 초점을 맞춘 객체이다.

예시 1: 경기장 좌석이 지정석인 경우 좌석은 ENTITY이다. 좌석의 식별자는 좌석 번호이고 경기장에서 유일하다.

예시 2: 경기장 좌석이 빈 좌석을 찾아 앉는 일반석인 경우 좌석은 ENTITY가 아니다. 전체 좌석의 개수가 중요하고 좌석번호가 물리적으로 새겨져 있더라도 소프트웨어에서는 그 번호를 관리할 필요는 없다.

ENTITY 모델링

ENTITY의 기본적인 책임은 연속성을 확립하는 것이다. ENTITY의 속성이나 행위에 집중하기보다 ENTITY 객체의 가장 본질적인 특징만 정의한다. 개념에 필수적인 행위만 추가하고 그 행위에 필요한 속성만 추가한다.

식별 연산의 설계

각 ENTITY에는 다른 객체와 구분해줄 식별성을 만들어내는 수단이 반드시 있어야 한다. 식별에 사용되는 속성은 시스템내에서 유일해야 한다. 어떻게 두 객체가 개념적으로 동일한 ENTITY를 나타내는지 생각해봐야 한다. 이를 정의하려면 도메인을 이해해야 한다.

한 객체를 구분할 수 있는 실질적인 고유키가 없다면 각 객체에 ID를 부여한다.

VALUE OBJECT(값 객체)

개념적 식별성이 없는 객체를 VALUE OBJECT라고 한다.

ENTITY의 식별성을 관리하는 일은 아주 중요하나 그 밖의 객체에 식별성을 추가하는 것은 시스템 성능을 저해하고 분석 작업이 별도로 필요해진다. 모든 객체를 동일한 것으로 보이게 해서 모델이 복잡해진다.

VALUE OBJECT는 어느 것인지는 관심이 없고 무엇인지에 대해서만 관심이 있다. 색은 문자열이나 숫자와 마찬가지로 대표적인 VALUE OBJECT이다. 어떤 VALUE OBJECT는 다른 여러 객체를 조립한 것일 수 도 있다(레고 처럼).

VALUE OBJECT는 ENTITY를 참조할 수도 있다. 데이트 코스가 있다면 각각의 장소가 있을 것이다. 데이트 코스는 장소들을 참조하는 세 객체가 ENTITY이더라도 데이트 코스 자체는 VALUE OBJECT이다.

모델에 포함된 어떤 요소의 속성에만 관심이 있다면 그것을 VALUE OBJECT로 분류해야 한다.
VALUE OBJET는 불변적으로 다뤄야 한다.
VALUE OBJECT에 식별성을 부여하지 말고 ENTITY를 유지하는데 필요한 설계상의 복장성을 피해야 한다.

VALUE OBJECT의 설계

두 사람이 동일한 이름 가지고 있다고 해서 동일 인물인 것은 아니다. 그래서 이름을 나타내는 객체는 서로 바꿀 수 있다. Name 객체는 두 Person 객체 간에 공유할 수 있다. 그러나, Name객체가 공유된다면 한사람의 이름이 바뀌면 다른 사람의 이름도 바뀔 것이다. 이러한 이유로 VALUE OBJECT는 불변적이어야 한다.

VALUE OBJECT는 많아지는 경향이 있어서 성능 최적화를 위한 대안을 마련해야 할 수도 있다. 각 전기 콘센트가 개별 VO라면 하나의 주택도면에도 수백개의 VO가 있을 지도 모른다. 그러나 콘센트를 단순이 한 콘센트 인스턴스를 공유해서 수백번에 걸쳐 같은것을 가리키게 할 수 도 있다(FLY WEIGHT 디자인 패턴).

변경가능성을 허용하는 경우

VALUE가 자주 변경되는 경우
객체 생성/ 삭제에 비용이 많이 드는 경우
VALUE를 공유할 일이 많지 않은 경우

VALUE의 구현이 변경 가능하다면 공유해서는 안된다.

SERVICE(서비스)

SERVICE는 모델에서 독립적인 인터페이스로 제공되는 연산으로써 도메인 객체(ENTITY나 VO)로는 어울리지 않고 도메인 연산이나 행위에 대한 책임을 가지고 있는 모델이다.

필요한 도메인 기능을 ENTITY나 VO에 억지로 맡게 하면 모델에 기반을 둔 객체의 정의가 왜곡될 수 있다.

SEVICE는 독립적인 인터페이스로 제공되는 연산이다. 이름은 UBIQUITOUS LANGUAGE에서 유래하거나 UBIQUITOUS LANGUAGE에 도입돼야 한다. 매개변수와 결과는 도메인 객체여야 한다.

잘 만들어진 SERVICE의 특징

연산이 원래부터 ENTITY나 VALUE OBJECT의 일부를 구성하지 않고 도메인 개념과 관련되어 있다.
인터페이스가 도메인 모델의 외적 요소의 측면에서 정의된다.
상태를 갖지 않는다.

MODULE(모듈)

모듈로 쪼개지는 것은 코드가 아닌 도메인 개념이다.

어떤 사람이 한 번에 생각해낼 수 있는 양은 한계가 있다(낮은 결합도 필요).

일관성이 없는 단편적인 생각은 이해하기 어렵다(높은 응집도 필요).

어떤 MODULE을 분석할 때 해당 MODULE의 내용물과 상호작용하는 것에 대해 조금만 알고 있어도 분석이 가능해진다.

MODULE 이름은 UBIQUITOUS LANGUAGE로 구성된다. MODULE과 그 이름은 도메인에 통찰력을 줄 수 있어야 한다.

MODULE과 그 안에 도메인 개념만으로도 그 자체를 이해할 수 있어야 한다.

도메인 주도 설계 - 4. 도메인의 격리

wookkl — Mon, 15 Apr 2024 09:44:15 +0900

본 내용은 에릭 에반스의 도메인 주도 설계를 공부하면서 제 나름대로 이해하기 쉽게 정리한 글입니다.

이해가 어려우시다면 댓글 부탁드립니다.

LAYERED ARCHITECTURE(계층형 아키텍처)

도메인코드가 도메인과 관련이 없는 다른 코드와 같이 섞일 경우 도메인 코드를 이해하기가 굉장히 힘들어진다. 도메인 코드와 UI가 같이 섞일 수 경우 UI를 변경하는 것이 실직적으로 업무 로직을 변경하는 것으로 이어질 수 있다.

복잡한 소프트웨어의 경우 관심사의 분리가 필요하다.

소프트웨어 시스템을 분리하는 방법 중에 하나인 LAYERED ARCHITECTURE는 널리 사용되고 있다. LAYERED ARCHITECTURE는 몇개의 일반화된 계층으로 나눈 방법이다. 한 계층의 모든 요소는 오직 같은 계층에 존재하는 요소나 계층상 아래에 위치한 요소에만 의존한다는 원칙이 있다.

일반적인 LAYERED ARCHITECTURE의 계층 구성

사용자 인터페이스	사용자에게 정보를 보여주고 사용자의 명령을 해석하는 일을 담당
응용 계층	소프트웨어가 수행할 작업을 정의하고 표현력 있는 도메인 객체가 문제를 해결하게 위임하는 작업. 업무상 중요하거나 다르 시스템의 응용 계층과 상호작용하는 작업을 책임짐 여기에는 업무 규칙이나 지식이 포함되어 있지 않음.
도메인 계층	업무 개념과 업무 상황에 관한 정보, 업무 규칙을 표현하는 일을 책임짐
인프라스트럭처 계층	상위 계층을 지원하는 일반화된 기술적 기능을 제공. 도메인 영속화이 대표적. 또한 인스라스트럭처 계층은 아키텍처 프레임워크를 통해 이 LAYERED ARCHITECTURE 패턴을 지원할 수도 있음

복잡한 프로그램을 여러 개의 계층으로 나누는 것은 중요하다. 응집력있고 오직 아래에 있는 계층에만 의존하는 방식으로 각 계층에서 설계를 발전시켜야 한다 도메인 모델과 관련된 코드는 모두 한 계층에 모으고 다른 코드와 격리 시켜야 한다. 그래야 도메인 모델을 표현하는 것에만 집중할 수가 있다.

계층간 관계

각 계층은 의존성을 한 방향으로만 둬서 느슨하게 결합된다. 상위 계층은 하위 계층과 동일한 계층의 공개 인터페이스를 호출하고 참조한다. 하위 객체가 상위 계층과 소통해야할 경우 콜백(callback)이나 OBSERVER(관찰자) 패턴을 고려해볼 수 있다.

SMART UI(지능형 UI) "안티 패턴"

도메인 주도 설계 접근법과 완전히 다른 접근법이다.

모든 업무 로직을 사용자 인터페이스에 넣는 패턴이다. 애플리케이션을 작은 기능으로 나누고 나눈 기능을 UI로 구현해서 업무 로직을 나눈 UI에 들어가게 한다. 이러한 SMART UI는 도메인 주도 설계 맥락에서는 안티 패턴으로 간주된다. 특정한 상황에서는 적합할 수도 있다.

장점

애플리케이션이 단순한 경우 생산성이 높고 효과가 즉각적이다.
배우기 쉽다.
요구사항 분석 단계에서 결함이 생기더라도 사용자에게 프로토타입을 배포한 후 요구사항에 맞게 변경해서 문제를 해결할 수 있다.
관계형 데이터베이스와 잘 아울리고 데이터 수준의 통합이 가능하다.
4세대 언어와 잘 어울린다.
빠르게 유지보수가 가능하다.

단점

데이터베이스 이용하는 방식 말고는 여러 애플리케이션을 통합하기가 어렵다.
행위를 재사용하지 않고 업무 문제에 대핸 추상화가 이뤄지지 않는다. 업무 규칙이 중복된다.
추상화의 부재로 리팩터링이 제한된다.
복잡성이 압도되어 애플리케이션 성장 경로가 막힌다. 풍부한 행위를 갖출 수 없다.

도메인 주도 설계 - 3. 모델과 구현의 연계

wookkl — Tue, 9 Apr 2024 09:55:19 +0900

본 내용은 에릭 에반스의 도메인 주도 설계를 공부하면서 제 나름대로 이해하기 쉽게 정리한 글입니다.

이해가 어려우시다면 댓글 부탁드립니다.

MODEL-DRIVEN DEGISN(모델 주도 설계)

도메인 주도 설계에서는 초기 분석 단계에 도움될 뿐 아니라 설계의 기반이 되는 모델이 필요하다. 이 모델 주도 설계는 도메인 주도 설계에서 필요로 하는 모델링 접근법이다.

설계가 도메인 모델과 대응하지 않는다면 그 모델은 가치가 앖고 소프트웨어의 정확함도 의심스러워진다. 또한 모델과 설계 기능 사이의 복잡한 대응은 이해하기 힘들고 유지보수가 불가능해진다. 분석과 설계가 분리된다.

모델 주도 설계는 도메인 모델을 있는 그대로 반영해서 설계와 모델의 대응시키는 방법론이다. UBIQUITOUS LANGUAGE(보편 언어)를 지원하고 분석과 설계를 만족하는 단 하나의 모델을 만들어내야 한다. 구현과 모델을 일치시키려면 보통 객체지향 프로그래밍과 같은 모델링 패더라임을 지원하는 소프트웨어와 언어가 필요하다

HANS-ON MODELER(실천적 모델러)

코드를 작성하는 사람이 모델에 책임을 느끼지 못하거나 애플리케이션을 대상으로 모델이 동작하게 만드는 법을 모르면 그 모델은 소프트웨어와 무관해진다. 개발자는 코드의 변경이 모델의 변경이라는 점을 인식해야한다.

또한, 모델러가 구현 프로세스와 분리되면 구현상의 제약조건을 감안하는 능력을 잃어버리게 된다. MODEL-DRIVEN DEGISN을 코드로 만드는 과정은 협업을 통해 알 수 있는데, 설계자(모델러)가 구현을 하지 못하면 개발자와 업무의 단절이 생겨 숙련된 설계자의 지식과 솜씨는 개발자에게 전해지지 못한다.

모델에 기여하는 모든 기술자는 역할과는 상관없이 코드를 접하는데 어느정도 시간을 투자해야 한다. 코드를 변경하는 책임이 있는 팀원들은 코드를 통해 모델을 표현하는 법을 반드시 배워햐 한다. 모든 개발자는 모델에 관한 토의에 참여해야하고 도메인 전문가와 접촉해야 한다. 모델에 기여하는 사람들은 의식적으로 개발자와 UBIQUITOUS LANGUAGE를 토대로 모델의 아이디어를 나눠야 한다.

도메인 주도 설계 - 2. 의사소통과 언어 사용(UBIQUITOUS LANGUAGE)

wookkl — Thu, 4 Apr 2024 09:48:52 +0900

본 내용은 에릭 에반스의 도메인 주도 설계를 공부하면서 제 나름대로 이해하기 쉽게 정리한 글입니다.

이해가 어려우시다면 댓글 부탁드립니다.

문제

공통 언어가 없는 프로젝트는...

개발자가 도메인 전문가를 위해 자신들의 언어를 번역해줘야 함
도메인 전문가도 개발자 간, 다른 도메인 전문가 간의 언어를 번역해줘야 함
심지어 개발자 사이에서도 서로 번역해줘야함

이렇게 되면 일상적인 토론에서 쓰이는 용어가 코드에 녹아는 용어와 단절된다. 번역은 의사소통을 무디게 하고 지식 탐구는 빈약하게 만든다.

UBIQUITOUS LANGUAGE(보편 언어)

프로젝트 팀원들 사이에 탄탄한 토대가 될 보편 언어가 필요하다. 도메인 모델이 이 보편 언어의 근간을 제공하고 소프트웨어 구현에 이르기까지 연결할 수 있다. 보편 언어는 개발자와 도메인 전문가 등 프로젝트 팀원들 사이에 적용되는 공통된 언어이다. 한 팀에서 특정 도메인 모델이 A와 B로 부를 수 있으면 안되고 둘 중 하나로 통일해서 불러야 한다는 의미이다.

보편 언어는 개발자 사이에서 소프트웨어 결과물뿐만 아니라 업무와 기능을 기술할 때도 사용해야 한다. 하지만, 초기 도메인 모델은 이정도 수준까지 못미치는데 지식 탐구를 통해서 가능해진다.

보편 언어를 사용하다보면 모델의 취약점이 발견되는데 이 취약점이 해결되면 도메인 모델이 변화하게 되고 소프트웨어 코드상 클래스나 메서드등 바뀌게 될 것이다.

정리하면 도메인 모델을 언어의 근간으로 사용해야 한다. 팀 내 모든 의사소통과 코드에서 보편언어를 끊임없이 적용하는데 전념해야 한다. 특히 말할 떄 동일한 보편 언어를 사용해야 한다.

UBIQUITOUS LANGUAGE(보편 언어)의 변화가 곧 모델의 변화라는 것을 인식해야 한다.

한 팀, 한 언어

개발자들이 만든 모델들은 도메인 전문가들도 이해가 가능해야 한다. 설계에는 도메인 전문가와 관련 없는 기술도 있지만 모델의 핵심은 도메인 전문가가 이해할 수 있어야 한다. 도메인 전문가와 개발자 사이에 언어적 분열이 일어나면 안 된다.

문서와 다이어그램

다이어그램은

의사소통과 설명의 수단이며 브레인스토밍을 촉진한다. 대신, 다이어그램은 최소화(3~5개정도)됐을 때 가장 좋다.
모든 객체 모델을 포괄하는 다이어그램은 의사소통과 설명이라는 목적을 달성하지 못하기 때문에 좋지 않다.
모델이 나타내는 개념의 의미와 모델내 객체의 행위를 전달할 수 없는데 이 부분은 별도의 텍스트나 대화의 몫으로 남는다.
보조적인 역할일뿐이다.

설계의 생생한 세부사항은 코드에 담긴다. 모델은 다이어그램이 아니라는 것을 명심해야 한다

문서는

코드와 말을 보완하는 역할을 해야한다.
코드가 이미 잘 하고 있는것을 하려고 해서는 안 된다.
유효한 상태를 유지하고 최신 내용을 담고 있어야 한다.
UBIQUITOUS LANGUAGE(보편언어)와 상호작용 해야한다.

이 책의 요점은 하나의 모델이 구현, 설계, 의사소통의 기초가 되어야 한다는 것이다. 각기 다른 모델은 갖추는 것은 바람직하지 않다.

도메인 주도 설계 - 1. 지식 탐구

wookkl — Tue, 2 Apr 2024 23:33:02 +0900

본 내용은 에릭 에반스의 도메인 주도 설계를 공부하면서 제 나름대로 이해하기 쉽게 정리한 글입니다.

이해가 어려우시다면 댓글 부탁드립니다.

지식탐구

지식 탐구는 혼자서 하는 활동이 아니다. 개발자가 도메인 전문가와 같이 협업하여(질문과 설명이 오가며) 도메인에 대한 지식을 이해하고 어떻게 동작하는지 알아가는 것이다. 이를 기반으로 다이어그램같은 도구로 초기 모델을 작성할 수 있다.

지식 탐구를 진행하면 다음과 같은 활동들이 거치게 된다.

모델과 구현의 연계: 도메인 모델과 구현이 본질적으로 연결된다.
모델을 기반으로 하는 언어 정제: 모델을 기반으로 용어들이 통일되고 용어들로 문장을 구성할 수 있게 된다. 별도의 해석 없이 문장을 명확히 이해할 수 있게 된다.
풍부한 지식이 담긴 모델 개발: 모델은 단순히 데이터 스키마가 아닌 복잡한 문제를 해결하는데 필요한 풍부한 지식이 담긴다.
모델의 정제: 모델이 점차 완전해지며 중요한 개념이 더해진다. 쓸모없는 개념들은 제거된다.
브레인 스토밍과 실험: 풍부한 지식이 담긴 모델을 발견하고 정제하기 위해 브레인스토밍을 진행하면서 수백가지 모델들이 실험/시도하고 평가된다.

지속적인 학습

소프트웨어를 작성하기 시작할 떄는 충분히 도메인에 대해 알지 못한 상태에서 시작한다. 그래서 지속적인 학습으로 의식적으로 지식을 함양해야 한다.

풍부한 지식이 담긴 설계

도메인에 관련된 엔티티만큼 실제 업무 활동과 규칙도 중요한데, 지식탐구는 이러한 부분에 대해 통찰력을 준다. 지식탐구는 규칙을 명확하게 하고, 구체화 하며, 고려할 범위가 아닌 것들은 배제하게 된다.

심층 모델

유용한 모델은 겉으로 드러나 있는 경우가 거의 없다. 지식 탐구를 통해 도메인과 애플리케이션의 요구사항을 이해하게 되면서 처음에 중요하다고 생각했던 피상적인 요소를 버리거나 관점을 바꾼다. 문제의 핵심을 관통하는 심층적인 모델이 서서히 나타나기 시작한다.

지식 탐구는 팀 내 지식을 가치있는 모델로 만든다. 지식탐구는 탐험과도 같아서 어디서 끝나게 될지 알지 못한다.