잡동사니

안녕하세요. yeTi입니다. 오늘은 도메인 주도 설계 4부를 읽고 난 느낌을 기록하려고 합니다. 지난 편에 이어 오늘은 4부(전략적 설계)의 2편입니다. 15장 디스틸레이션 - CORE DOMAIN (핵심 도메인) 지금까지 맥락을 살펴보면 지식을 얻고 쌓아나가며 언어의 맥락을 일치해 같은 개념을 가지는 것을 중심에 두고 에릭 에반스는 이야기를 풀어나가고 있습니다. 이를 달성하기 위한 중심 패러다임은 MODEL-DRIVEN DESIGN 을 채용하고 있고 경험의 누적에 따른 통찰력이 모델로 표현되어야 한다고 말합니다. 모델이 설계를 더 잘 지원하기 위해 정제되는 것처럼 설계 또한 새로운 통찰력을 도메인에 반영하기 위해 정제돼야 한다. - p.172, 7장 언어의 사용 - 도메인 격리 해당 장에서는 지식을 어..

안녕하세요. yeTi입니다. 오늘은 도메인 주도 설계 4부를 읽고 난 느낌을 기록하려고 합니다. 4부도 내용이 많아서 작은 부분으로 나눠서 기록합니다. 오늘은 4부의 1편입니다. 14장 모델의 무결성 유지 - BOUNDED CONTEXT 2018년부터 MSA를 흉내 내면서 각 서비스 간 경계를 나누는 방법으로 BOUNDED CONTEXT를 알게 됐습니다. 그러나 BOUNDED CONTEXT를 단순하게 서비스 단위를 나누는 경계로 인식하니 어떻게 사용해야 좋은지 알 수 없어 어렵게 다가왔습니다. 에릭 에반스가 말하는 BOUNDED CONTEXT는 명료합니다. 모델 컨텍스트란 모델에서 사용된 용어를 특정한 의미로 의사소통하기 위한 조건의 집합이다. - p.362 동일한 모델이라도 맥락에 따라 내포하는 의미와..

안녕하세요. yeTi입니다. 오늘은 에릭 에반스의 도메인 주도 설계를 읽다가 도메인의 의미와 도메인 주도라는 것의 의미를 생각해본 결과를 공유하고자 합니다. 도메인이란 에릭 에반스의 DDD 함께 읽기를 진행하면서 15장 디스틸레이션에 핵심 도메인을 다시 읽을 기회가 생겼습니다. 그런데 문득 도메인이라는 단어를 굉장히 모호한 개념으로 인식하고 있다고 느껴, 무엇을 의미하는지 찾아보고 싶어졌습니다. 그래서 먼저 영어사전에서 도메인이라는 단어의 뜻을 찾아봤습니다. an area of interest or an area over which a person has control, 관심 영역 또는 개인이 통제할 수 있는 영역 신기하게도 관심 영역이었습니다. 막연하게 어떤 분야, 업무 정도로 생각했던 개념이 보다 단..

안녕하세요. yeTi입니다. 오늘은 도메인 주도 설계 의 3부의 읽은 후기를 기록하려고 합니다. 3부의 2편입니다. 선언적 설계 선언적 설계는 대상에 따라 다양한 의미를 지닐 수 있지만 일반적으로 일종의 실행 가능한 명세(executable specification)로서 프로그램 전체 혹은 프로그램의 일부를 작성하는 방식을 의미한다. - p.289 선언적 설계는 프로그램을 생성하는 방법이 일종의 성배에 해당한다는 구절을 보면서 이전에 안영회 대표님께서 알려주신 MDD가 떠올랐습니다. (폭포수 방식 설계는 기술 부채를 남긴다) 해당 글에서 다음과 같이 언급합니다. 다양한 맥락을 포용해야하는 비즈니스 시스템에서 마치 '자동화' 결과물이 모든 프로그램을 대체하는 일인 것처럼 생각하면 큰 오산입니다. 결론적으로..

안녕하세요. yeTi입니다. 오늘은 도메인 주도 설계 의 3부의 읽은 후기를 기록하려고 합니다. 3부는 내용이 많이서 2편으로 나눠서 기록합니다. 지속적인 리팩터링을 통해 심층모델로 도약할 수 있다. 리팩터링이란 소프트웨어의 기능을 수정하지 않고 설계를 다시 하는 것을 의미합니다. 관건은 사전에 모든 설계 결정을 내리기보다는 기존의 기능은 유지한 채 끊임없이 코드를 변경하면서 설계를 좀 더 유연하게 개선하거나 이해하기 쉽게 만드는 과정이라는 것이죠. #XP 에서는 점진적 설계를 말하고 #TDD 에서는 작은 목표를 기반으로한 지속적인 리팩토링을 말합니다. (모두 켄트 벡의 저서입니다.) DDD에서는 리팩터링의 수준에 대해 이야기 합니다. 리팩터링의 목표는 개발자가 단순히 코드가 수행하는 바를 이해하는 것뿐..

안녕하세요. yeTi입니다. 오늘은 도메인 주도 설계 의 2부의 읽은 후기를 기록하려고 합니다. 도메인을 격리하자 도메인의 격리를 보편적으로 할 수 있는 방식은 LAYERED ARCHITECTURE 입니다. 객체지향 프로그램을 개발하면서 가장 쉬운 방법으로 도메인 코드와 도메인과 관련없는 코드를 혼재하는 것입니다. 그러나 이렇게 되면 도메인과 관련된 코드를 확인하고 추론하기가 힘들어지고 모델 주도적인 객체를 구현하는 것이 비현실적인 이야기가 돼버립니다. 객체지향의 5대원칙 중 하나인 관심사의 분리가 중요한 요소로 언급되는 것처럼 소프트웨어 시스템을 분리하는 방법 중 보편적으로 사용하는 것이 LAYERED ARCHITECTURE 입니다. 그 외의 다수의 패턴들이 풀고자 했던 문제 중 하나는 느슨한 결합을 ..

안녕하세요. yeTi입니다. 오늘은 도메인 주도 설계 의 1부의 읽은 후기를 기록하려고 합니다. 책을 선택한 이유 조영호님의 객체지향의 사실과 오해를 보면 도메인 모델을 기반으로한 객체 설계를 말합니다. 도메인 모델로 객체 지도를 만들어라. 그리고 JPA 의 repository 의 주석을 보면 DDD 에 의해 정의된 메카니즘이라고 표현합니다. 그렇게 DDD 를 읽기 시작했습니다. 현실의 복잡성을 풀어나가자 그런데 서문을 읽고 장황하게 설명된 표현들이 도메인 모델을 이해하고 현실의 복잡성을 풀어나가는것이 소프트웨어 개발의 본질이라고 말하는거 같습니다. 머릿속에서 명쾌하게 정리되는 느낌은 없지만 좋은 설계를 목표로, JPA가 지향하는 메카니즘을 이해하는 것을 목표로 읽어나가야 겠습니다. 지식을 보전하고 계승..