본문 바로가기

Concepts135

DDD - Module (package) - 출처: 도메인 주도 설계 - 에릭 에반스 - Module (package) 인간이 한번에 받아들일 수 있는 인지력은 한계가 있기 마련이다. 만약 legacy 시스템을 운영해야 하는 업무를 수행한다고 가정해보자. legacy가 방대하다면 해당 시스템을 한번에 이해하기란 쉽지 않을것이다. 그럼 어떻게 해당 시스템을 분석할것인가? 가장 기본적인 접근법은 특정 단위로 나누어서 분석하고 그들간의 관계를 파악하는것이다. module은 왜 필요한가? 위에서 언급한대로 인간의 인지적인 과부하를 줄이기 위한 단위가 필요한데 이것이 바로 module 또는 package 라고할 수 있다. module을 분석하는 관점에는 2가지가 있다. 하나는 module과 module간의 관계를 파악하는 관점이고, 다른 하나는 해당 m.. 2022. 8. 7.
DDD - Service - 출처: 도메인 주도 설계 - 에릭 에반스 - 들어가기전에 DDD의 Service를 언급하기전에 한 가지 확실히 해두고 싶은 점이 있다. 이 글에서 언급하고자 하는 DDD의 service는 project에서 많이들 구성하는 controller, service, repository 계층 에서 말하는 응용 계층의 service와 다르다. - Service service는 개념적으로 어떤 객체에도 종속되지 않는다. 어떤 객체에 종속시키기 애매한 무엇인가가 있다면 억지로 해당 객체로 밀어넣으려고 하기 보다는 service로 추출하여 모델링에 포함시키는 방법도 존재한다. 보통 service는 entity나 VO에 포함되지 않는 도메인의 연산이 활동이나 행동으로 나타나는 경우가 많다. 이런 도메인 연산은 여러 도.. 2022. 8. 7.
DDD - Value Object - 출처: 도메인 주도 설계 - 에릭 에반스 - Value-Object (VO) VO는 개념적인 식별성이 없고 사물의 어떤 특징을 묘사하는 객체이다. 예를 들어 어떤 아이가 펜으로 그림을 그리려고 하고 있다고 가정해보자. 만약 똑같은 색과 굵기와 모양의 펜이 2개가 있다면 아이는 어떤 펜을 사용해도 도 크게 개의치 않을것이다. VO는 설계요소가 어느것인지가 아닌 무엇인지에 관심이 있다고 할 수 있다. - "주소"는 VO인가? VO와 Entity에 관련된 글이나 자료를 보다 보면 자주 떠오르는 유형의 의문점이 있다. VO와 Entity의 차이 혹은 "주소"는 VO일까? 와 같은 유형의 질문이다. 이 질문에 해답역시 앞의 Entity 장에서 살펴본것과 같이 도메인에서 해결하고자 하는 문제에 따라 다르다. 전.. 2022. 7. 19.
DDD - Entity - 출처: 도메인 주도 설계 - 에릭 에반스 - 개요 객체는 본질적으로 속성이 아닌 연속성과 식별성으로 정의 된다. 속성은 객체의 생명주기 동안 계속해서 변해간다. 어릴 때의 나와 현재의 나를 비교해보면 키, 친구들 많은 것이 변했으며 심지어는 이름이 변하는 경우도 있다. 하지만 식별성은 지속되는데 어릴 때의 '나'와 지금의 '나'는 동일하다. Entity는 생명주기 동안 형태와 내용은 급격하게 변하지만 연속성은 유지해야 한다. 그리고 이런 Entity를 추적하려면 식별성이 정의되어 있어야 한다. 우리가 좌석 예약 시스템을 만든다고 가정해보자. 만약 좌석을 예약하고 발급받은 입장권에 좌석번호가 명시된 경우 좌석번호를 Entity의 식별성으로 사용해야 한다. 반면 어떤 경우에는 단순히 일반석이라고 등급만 .. 2022. 7. 17.
DDD - S/W와 모델 - 출처: 도메인 주도 설계 - 에릭 에반스 - S/W 에서 표현되는 모델 S/W 에서는 모델을 표현하는 주요 패턴으로 3가지 형태가 주로 사용된다. Entity: 어떤 객체가 영속성과 식별성을 지닐 때 VO: 다른 무언가의 상태를 기술하는 속성에 불과할 때 Service: 객체보다 행동/연산으로 더 명확하게 표현되는 경우 자바라면 class, Golang 이라면 struct로 표현하기만 하면 되는데 왜 굳이 Entity와 VO라는 개념을 도입해서 나누는지 의문을 가질 수도 있다. 굳이 이렇게 하는 이유는 특정 객체가 특정 패턴을 따르면 객체의 역할이 더욱 명확해져서 설계 결정을 하는데 도움이 되기 때문이다. Entity와 VO만 있으면 객체를 표현할 수 있는데 Service라는 개념은 왜 필요할까? .. 2022. 7. 16.
아키텍처 - 아키텍처 사고 - 출처: 이 글은 도서 '소프트트웨어 아키텍처 101'을 참조하여 작성된글입니다. - 개요 아키텍처 사고는 단순히 '아키텍처를 생각하는것'이라고 많은 오해를 하지만 아키텍처 관점에서 사물을 바라볼줄 알아야 하는것을 의미한다. 아키텍트의 사고방식은 크게 4가지 사고방식으로 나눌 수 있다. 아키텍처와 설계 차이의 이해 기술의 깊이보다는 폭넓은 지식의 이해 다양한 솔루션과 기술간의 Trade off 이해 비즈니스 동인(행동을 촉발시키는 내적 원인의 총칭)의 중요성이해(이 글에서는 다루지 않는다.) - 아키텍처 vs 설계 아키텍처와 설계의 차이점은 모호한 경우가 많다. 이를 이해하기 위해 전통적인(기존 시각의) 아키텍트와 개발자의 책임을 이해해보자. 아키텍트 비즈니스 요구사항을 분석하여 아키텍처의 특성(~성).. 2022. 3. 9.
DDIA - 그래프형 데이터 모델 - 이 글은 마틴 클레프만의 데이터 중심 애플리케이션 설계를 기반으로 작성되었습니다. - 개요 다대다 관계가 데이터 모델을 구별하는 중요한 기능임을 살펴봤다. 앞서 애플리케이션이 1:N 관계이거나 관계가 없다면 문서 모델이 적합하다고 하였다. 반면 관계형 모델은 M:N 을 다루기 수월하지만 데이터간 연결이 복잡해지면 그래프형 데이터 모델을 사용하는편이 자연스럽다. 그래프의 구성요소에는 정점(노드, 엔티티)과 간선(엣지, 관계, 호)이 있다. 예를 들어 소셜그래프에서 정점은 사람이며 간선은 사람간의 관계라고 할 수 있다. 웹 그래프에서는 정점은 웹이며 간선은 다른 페이지의 HTML 링크라고 할 수 있다. 위의 예제에서는 정점이 모두 같은 유형(type)을 예로 들었지만 그래프는 같은 유형의 데이터만 정점으.. 2021. 11. 21.
DDIA - 데이터를 위한 질의(query) 언어 - 이 글은 마틴 클레프만의 데이터 중심 애플리케이션 설계를 기반으로 작성되었습니다. - 데이터를 위한 질의 언어 관계형 모델이 등장했을 때 데이터를 질의하는 새로운 방법이 등장하였다. SQL 은 선언형 질의언어인 반면 IMS와 코다실은 명령형 코드를 사용해 DB 에 질의한다. 동물의 종 목록중에서 상어만 반환하는 코드를 작성한다고 가정해보자. 이를 명령형 코드로 작성하면 아래와 같이 작성할 수 있다. public List getSharks(List animals) { List sharks = new ArrayList(); for(Animal animal : animals) { if("Sharks".equals(animal.getFamily())) { sharks.add(animal); } } retur.. 2021. 10. 31.
DDIA - 관계형 모델과 문서 모델 - 이 글은 마틴 클레프만의 데이터 중심 애플리케이션 설계를 기반으로 작성되었습니다. - 개요 데이터 모델은 S/W 가 어떻게 작성되었는지와 문제를 어떻게 생각해야하는지에 대해서도 영향을 미친다. 대부분의 애플리케이션에서는 각 계층마다 데이터 모델에 대한 관점이 다르다. App. 개발자는 현실을 보고 객체, 데이터 구조, API를 모델링 한다. 데이터 구조를 저장할 때는 JSON, XML, RDB 테이블, 그래프와 같은 모델로 표현한다. DB S/W 엔지니어는 데이터를 메모리나 디스크에 표현하는 방법을 결정한다. 그리고 이 표현은 질의, 탐색, 조작, 처리할 수 있게 한다. 각 계층에서 명확한 데이터 모델을 제공하면 하위 계층에 대한 복잡성을 숨길 수 있다. - 관계형 모델 관계형 모델이라는 단어가 어색.. 2021. 10. 30.
DDIA - 신뢰성,확장성,유지보수성 - 유지보수성 - 이 글은 마틴 클레프만의 데이터 중심 애플리케이션 설계를 기반으로 작성되었습니다. - 개요 S/W 는 대부분 개발보다 유지보수를 할 때 많은 비용이 들어간다. 이런 유지보수에는 일반적으로 다음과 같은 항목들이 있다. 버그 수정 시스템 운영 유지보수 신규플랫폼 적용 기술채무 상환 신규 기능 추가 유지보수의 고충을 최소화하기 위해서는 지켜야하는 설계 원칙이 있다. 운용성: 운영팀이 시스템을 운영하기 쉽게 해야 한다. 단순성: 복잡도를 최대한 제거하여 새로운 엔지니어가 최대한 이해하기 쉬워야 한다. 발전성: 이후에 시스템을 쉽게 변경할 수 있어야 한다. 신뢰성과 확장성을 달성하는것은 그리 간단하지 않다. 그래서 위의 3 가지 항목을 염두해두면서 기본적으로 유지보수성을 달성하기위해 노력해야 한다. - 운영성.. 2021. 10. 25.

티스토리툴바