도메인9 DDD - 개념적 윤곽 - 출처: 도메인 주도 설계 - 에릭 에반스 - 개념적 윤곽(Conceptual contour) 코드를 개발하다보면 유연하게 조합할 수 있도록 작은 크기로 기능을 나누기도 하며, 복잡성을 캡슐화하기 위해 기능을 더 큰 단위로 통합 하기도 한다. 이런 방법들은 지나치게 단순해서 일반 원칙으로 적용하기에는 부적절하다. 하지마 이런 방법들은 문제를 해결하기 위한 동기를 부여한다. 모델 혹은 설계를 구성하는 요소가 모놀리식 구조이면 기능이 중복되어 클라이언트는 인터페이스로부터 유용한 정보를 일부만 파악가능하다. 반대로 클래스와 메소드를 잘게 나누면 작은 객체들의 협력 방식을 이해하고 있어야 하기 때문에 클라이언트 객체가 무의미하게 복잡해진다. 도메인에는 잠재적인 일관성이 존재한다. 특정 모델을 발견하면 나중에 .. 2022. 10. 31. DDD - Assertion - 출처: 도메인 주도 설계 - 에릭 에반스 - 개요 복잡한 계산을 하는 부분은 앞서 살펴본 side effect free function 으로 분리하면 문제의 난이도를 낮출 수 있다. 하지만 여전히 부수효과가 있는 명령(command)는 Entity 에 남아있으며 개발자는 이런 명령의 영향력을 이해해야 한다. 단순한 명령의 경우 코드를 조사하는것만으로도 결과를 예측할 수 있다. 하지만 앱의 규모가 커지면 작은 부분을 조합하여 큰 부분을 구성하는 설계가 등장하기 마련이고, 이럴 경우 사용자가 하나의 명령을 호출하면 다른 명령을 호출하게 된다. 이렇게 되면 각 호출되는 명령을 이해해야 해서 캡슐화가 깨지게 된다. 내부를 조사하지 않고 설계 요소의 의미와 연산 실행결과를 이해하는 방법이 필요하다. 이를 "단.. 2022. 10. 22. DDD - Side effect free function - 출처: 도메인 주도 설계 - 에릭 에반스 - 연산과 함수 연산은 명령(command, modification)과 질의(query)로 나눌 수 있다. 명령(command, modification): 변수값을 변경해서 시스템의 상태를 변경 질의(query): 변수안에 저장된 데이터에 접근하고, 저장된 데이터를 기반으로 계산을 수행 함수는 부수효과를 일으키지 않고 결과를 반환하는 연산이다. 여러번 호출 해도 무방하며 매번 동일한 값을 반환한다. - 명령과 질의의 분리 명령과 질의는 서로 엄격하게 다른 연산으로 분리해야 한다. 변경을 발생시키는 메서드는 도메인 데이터를 반환하지 않고 단순하게 유지해야 한다. 또는 명령과 질의를 분리하는 대신 연산의 결과를 표현하는 새로운 VO(Value-Object)를 생성.. 2022. 10. 22. DDD - Service - 출처: 도메인 주도 설계 - 에릭 에반스 - 들어가기전에 DDD의 Service를 언급하기전에 한 가지 확실히 해두고 싶은 점이 있다. 이 글에서 언급하고자 하는 DDD의 service는 project에서 많이들 구성하는 controller, service, repository 계층 에서 말하는 응용 계층의 service와 다르다. - Service service는 개념적으로 어떤 객체에도 종속되지 않는다. 어떤 객체에 종속시키기 애매한 무엇인가가 있다면 억지로 해당 객체로 밀어넣으려고 하기 보다는 service로 추출하여 모델링에 포함시키는 방법도 존재한다. 보통 service는 entity나 VO에 포함되지 않는 도메인의 연산이 활동이나 행동으로 나타나는 경우가 많다. 이런 도메인 연산은 여러 도.. 2022. 8. 7. 객체지향의 사실과 오해 - 개념, 명세, 구현 - 이 글은 조영호의 객체지향의 사실과 오해를 기반으로 작성되었습니다. (가능하면 꼭 읽어보는것을 추천드립니다.) - 개념, 명세, 구현 UML 관련 서적중 마틴 파울러의 UML Distilled 2판 에서는 객체 지향 설계를 개념 관점, 명세 관점, 구현 관점으로 구분한다. 우선 개념 관점은 도메인안에 존재하는 개념과 개념간의 관계를 나타낸것이다. 도메인은 앞에서 말했듯이 사용자가 관심을 가지는 분야를 의미한다. 이 관점에서는 실제 도메인의 규칙을 최대한 유사하게 반영하는것이 핵심이다. 명세 관점부터는 소프트웨어의 세계로 넘어온다. 명세 관점에서는 What/Who 사이클에서 What 에 해당하는 무엇에 초점을 맞추어서 객체의 인터페이스에 해당하는 관점에 집중한다. 구현 관점은 우리와 같은 프로그래머가 .. 2021. 8. 29. 객체지향의 사실과 오해 - 기능과 구조의 통합 - 이 글은 조영호의 객체지향의 사실과 오해를 기반으로 작성되었습니다. (가능하면 꼭 읽어보는것을 추천드립니다.) - 도메인 모델, 유스케이스 그리고 책임-주도 설계 시스템이라는 것은 사용자가 첫번째로 만나게 되는 객체이다. 사용자 입장에서 시스템은 자신과의 협력에서 자신의 요청을 처리하는 하나의 객체로 볼 수 있다. 시스템은 자신안에 더 작은 객체들을 갖고 있으며, 사용자로부터 받은 책임을 더 작은 객체들로 적절하게 분배해야 한다. 여기에서 책임-주도 설계가 등장한다. 유스케이스는 사용자에게 제공할 기능을 시스템의 책임으로 볼 수 있게 한다. 즉 사용자로 부터 처음으로 메시지를 수신하는 출발점의 역할을 한다. 그 이후에는 시스템이 안정적인 도메인 모델에 기반하여 기능을 수용하고 객체들로 책임을 분배한다.. 2021. 8. 28. 객체지향의 사실과 오해 - 구조 - 이 글은 조영호의 객체지향의 사실과 오해를 기반으로 작성되었습니다. (가능하면 꼭 읽어보는것을 추천드립니다.) - 도메인 모델 은행에서는 고객의 자산을 관리하고 보호하기 위해, 게임에서는 재미를 위해 또 병원에서는 환자의 진료 및 업무 관리를 위해 소프트웨어를 사용한다. 이처럼 사용자가 프로그램을 사용하는 대상 분야를 도메인이라고 한다. 모델은 복잡한 세상속에서 필요한 것들을 추려낸것이다. 만약 필요한 것만 추려내고 문제와 관련없는 나머지 세부사항들을 무시하는 추상화를 한 모델이 없다면 너무나 복잡하고 고려할것이 많아서 프로젝트 기간이 아무리 길다 한들 개발자들은 소프트웨어를 만들어내지 못할것이다. 이렇게 도메인과 모델의 정의를 고려할 때 도메인 모델이란 사용자가 소프트웨어를 사용하는 대상 분야에서 .. 2021. 8. 26. 객체지향의 사실과 오해 - 기능과 구조 - 이 글은 조영호의 객체지향의 사실과 오해를 기반으로 작성되었습니다. (가능하면 꼭 읽어보는것을 추천드립니다.) - 문제를 접근하는 두 가지 방법 낯선 여행지에서 목적지를 찾아가는 방법에는 여러 가지가 있다. 어떤 사람은 모르는 사람에게 길을 묻고, 어떤 사람은 지도를 보고 목적지를 찾아간다. 모르는 사람에게 길을 물으면서 찾아가는 해결법은 '기능적이고 해결책 지향적인 접근법(functional, solution-directed approach)' 라고 할 수 있다. 가령 '길을 따라 얼마쯤 가다가 어떤 랜드마크가 보이면 다른길로 가세요'와 같은 식이다. 반면 지도를 이용하는 방법은 '구조적이고 문제 지향적인 접근법(structural, problem-directed approach)' 이다. 지도는 .. 2021. 8. 26. JPA - 엔티티 맵핑 - 요구사항 분석과 맵핑 - 참조: 자바 ORM 표준 JPA 프로그래밍 - 실전 예제 책에서는 쇼핑몰을 만든다고 가정하고 몇 가지 요구사항을 통해 엔티티 맵핑을 적용해보는 과정이 있다. 내용을 다 기술할수는 없고 몇 가지 생각해볼 내용들이 있다. 회원은 상품을 주문할 수 있다. 주문시 여러 종류의 상품을 선택할 수 있다. - 도메인 모델 분석 JPA 는 도메인 모델을 다루는데에 있어서 Mybatis 보다 상당한 강점이 있다고 생각한다. Spring Data JPA 문서에서도 domain 이라는 단어자체가 상당히 많이 등장하며, Specifications 부분은 직접적으로 에릭 에반스의 DDD 에서 개념을 가져왔다고 말하고 있다. 위에서 언급한 요구사항 2 가지를 적용해보자. 위 그림은 회원, 주문, 제품간의 관계를 나타낸것이다... 2021. 6. 27. 이전 1 다음
