DDD Start 의 저자, 최범균님의 북콘서트가 있었다.

주제는 '수다' 부제는 약팔기.


DDD(Domain Driven Development) 의 난해함은 많은 개발자들에게 부담을 준다.

개발하는 비즈니스 로직의 복잡함을 해소 하기위한 해결책으로 제시된 것이 DDD 다.



독자의 곁으로 다가가는 저자의 사인회.

사인을 하면서 도란도란 이야기를 나누는 모습이 보기 좋았다.



저자의 사인 받기.

건강을 기원하는 말들을 적어주셨다.

건강제일!



지앤선 김지영 실장님의 인삿말을 시작으로 세미나가 시작된다.



쿠팡의 최용은님이 쿠팡의 정산과 관련하여 MSA(MicroService Architecture) 적용 사례에 대한 경험을 공유했다.

그러고보니!! 라이트닝 토크를 할 때 쯤 장진달님이 +_+) 안보이셨다.



DDD 를 하게 되면, CQRS(Command Query Responsibility Segregation) 에 대한 경험을 공유해주셨다.

2시간 만에 접수가 끝난 콘서트에 초대권을 미끼로 좋은 경험을 공유해주셨다.

테스트를 하다가 CQRS 를 하다가 DDD 공부도 하게 된 이야기.


간단하게 정리하자면 CUD(Create-Update-Delete) 와 R(Read) 를 분리하여 성능을 향상시키는 아키텍처에 대한 이야기랄까.....



최범균님과 박용권님이 DDD에 대한 질문에 대한 답변을 주거니 받거니 만담을 나눈다.



그리고 마무리!

DDD 에 대해서 좋은 예제와 함께 쉽게 풀어서 설명한

범균님의 책이 많이 팔릴 수 있기를 바란다. ^^



'logbook' 카테고리의 다른 글

오류를 느끼는 감각  (0) 2016.08.08
곧 나올 나의 두번째 번역서  (0) 2016.08.06
20160714; RecruitingDay: Developer  (0) 2016.07.15
20160619 KSUG 경력관리 세미나  (0) 2016.06.19
(0).5 M/M 의 신화  (0) 2016.05.11

도메인주도설계(Domain-Driven Design, DDD)  읽는 중



소프트웨어 시스템을 분리하는 방법.

계층화. 계층화의 핵심 원칙은 한 계층의 모든 요소는 오직 같은 계층에 존재하는 다른 요소나 계층상 "아래"에 위치한 요소에만 의존한다는 것이다. 위로 거슬러 올라가는의사소통은 반드시 간접적인 메커니즘을 거쳐야 하며...

계층화의 가치는 각 계층에서 컴퓨터 프로그램의 특정 측면만을 전문적므로 다룬다는 데 있다. 이러한 전문화를 토대로 각 측면에서는 더욱 응집력 있는 설계가 가능해지며, 이로써 설계를 더욱 쉽게 이해할 수 있다.


가장 바람직한 아키텍처 프레임워크라면 도메인 개발자가 모델을 표현하는 것에만 집중하게 해서 복잡한 기술적 난제를 해결한다.
...
프레임워크를 적용할 때 팀은 프레임워크의 목적에 집중해야 하는데, 그러한 프레임워크의 목적은 도메인 모델을 표현하고 해당 도메인 모델을 이용해 중요한 문제를 해결하는 구현을 만들어내는 데 있다.


한 프레임워크를 이용해 해결하기 힘든 갖가지 측면은 어려운 문제를 해결하고자...여러 프레임워크를 선택적으로 적용해서 극복할 수 있다. 프레임워크의 가장 유용한 기능만 분별력있게 적용한다면 구현과 프레임워크 간의 결합이 줄어들어 차후 설계 의사결정을 더욱 유연하게 내릴 수 있을 것이다.


도메인 로직이 프로그램상의 다른 관심사와 섞여 있다면 그와 같은 대응을 달성하기가 수월하지 않다. 따라서 도메인 주도 설계의 전제조건은 도메인 구현을 격리하는 것이다.

결국 도메인을 격리할 때의 가장 좋은 점은 부수적인 것을 배제하고 도메인 설계에만 집중할 수 있다는 것이다.


프로젝트에 도메인 모델은 있었지민 동작하는 소프트웨어를 개발하는 데 직접적으로 도움을 주지 않는 한 종이에 기록된 모델이 무슨 의미가 있겠는가?
...
도메인 주도 설계에서는 초기 분석 딘계에 도움이될 뿐 아니라 설계의 기반이 되는 모델이 필요하다.
...
코드와 그것의 기반이 되는 모델이 긴밀하게 연결되면 코드에 의미가 부여되고 모델과 코드가 서로 대응하게 된다.

DDD, chap 3. 모델과 구현의 연계


많은 개발자가 단지 프로그램 코드를 구성하는 데만 객체의 기술적 능력을 적용해 도움을 얻지만 객체 설계에서의 진정한 도약은 코드가 모델의 개념을 표현할 때 나온다.

모델에 기여하는모든 기술자는 프로젝트 내에서 수행하는 일차적인 역할과는 상관없이 코드를 접하는 데 어느 정도 시간을 투자해야만 한다. 코드를 변경하는 책임이 있는 모든 이들은 코드를 통해 표현하는 법을 반드시 배워야 한다. 모든 개발자는 모델에 관한 일정 수준의 토의에 깊이 관여해야 하고 도메인 전문가와도 접촉해야 한다.

국내의 많은 프로젝트들은 분석설계자와 개발자가 분리되어 있는 경우가 많다. 그 때문인지 분석설계된 모델이 개발자가 구현되는 단계에서 그 모습을 제대로 유지하지 못하고 구현 후에는 도메인 전문가들과 어울어지지 못하는 괴리감을 형성하며 불편해하는 경우가 잦다. 가능하다면, 프로젝트 초기부터 개발자들이 함께 참여하면서 분석설계를 하고 도메인을 정의하며 프로젝트를 시작해야 한다. 그러나 대부분의 프로젝트가 초기에 기획자와 아키텍트만 사전투입되고 개발자는 산발적으로 모집하여 진행하는 경우가 잦다. 이런 프로젝트는 대부분이... 실패할 가능성이 높다.


어디가서 도메인 설계를 해봤다고 말하려면 이 개념들을 자연스레 머리에 그리고 알기쉽게 설명해야하지 않을까??

발표자 : 김민재, 이경진
발표내용 : 소프트웨어 중심에 존재하는 복잡성에 도전장을 내밀다
DDD : Domain Driven Developemnet - 회사에서 새롭게 진행하는 프로젝트에서 사용하게되는 JPA와 Hibernate 를 이용하면서 DDD를 활용하게 되다.
∘ The String, Entertainer

∘ 목적(Objectives)


‣ Modeling in out
‣ 강사 -> Ubiquitous language <- 청중
발표자와 청중이 만나서 메시지를 주고받으면서 그에 대한 호응이 있어야 한다고 말함. 하지만, 발표자분은 본인이 말한 부분을 제대로 달성하지 못한 아쉬움이 있다.
‣ 멘토스 <-> 멘토,
‣ DDD 에릭 에반스 : http://artofsoftwaredev.tistory.com/94 강연
‣ 켄트 백 : Four Strategies : leap(건너뛰기) -> parallel(병렬화) -> stepping stone(가뿐하게 건너뛰기) -> simplification
‣ 질서유지
‣ 일관성
‣ 저장이 아니라 소화(지식을 단순히 보관하는 것이 아니라, 그것을 이해하고 활용(소화)하여 자신의 것으로 만드는 작업이 중요하다).
• 소화에서는 질문이 일어난다.
‣ 연계(Alignment)
• 계획(Plan)  vs. 일(Work)
• Plan to work, Work By plan
• 방향, 거리
• 머릿돌(capStone)과 건축(construction) : 머릿돌이 움직이는대로 몸체가 움직인다?
• 목적 vs 활동
∘ 1. Set Objectives
∘ 2. Compare
∘ 3. provide Direction
∘ 4. IT Activities

∘ 활동(Activies)
‣ 디자인(Design) vs. 프로세스(Process) : DDD는 디자인 책인가? 프로세스 책인가? DDD에서는 방법론에 대한 이야기를 많이 한다. XP, Agile
‣ 질문
• 애자일을 하면 모델이 필요없나요?
∘ 모델을 강조한다. Red -> Green, Refactoring
∘ 코딩의 생산성
∘ 고객의 필요에 대한 만족
‣ 해결책 :  DDD -> 디자인 & 프로세스 패턴 모음집
• Entitiy -> Relation -> Entitiy
• Boundary Context
‣ 어떤 문제가 있는가?
‣ 소통, 언어 : Ubiqutous Language Pattern
‣ 모델은 생각을 반영한다. 모델을 통해서 구현부분에서 작성자를 떠올릴 수 있다.
‣ 소통, Deep & Supple : 언어 + 모델
‣ 모델 -> Paradigm -> Design : Deep Model & Supple Design
‣ 통일성

• DDD 적용 사례(Reference) : 11번가
∘ CBD : DDD도 CBD와 유사한 Architect 구조를 유지하고 있다.
∘ A -> B -> C -> D : D에 대한
∘ 식별성




※ 발표... 들은 시간이 왜이리 아쉽냐....
  DDD에 관심을 가지는 이유는, 개발을 조금 더 객체지향적으로 할 수 있기를 바라는 개발자들의 바람 때문이다. 아직 우리나라에는 ORM을 바탕으로 하는 서비스나 애플리케이션들이 많지는 않다. 그래서 DDD에 대한 참고자료나 글이 적은 듯 하다. 나도 최근에 업무차원에서 JPA를 이용해서 ORM을 활용하게 될 것으로 보인다. 그래서 기대하고 트랙에 참가해서 들었는데 기대에 못미치는 아쉬운 점들이 많다.
  개인적으로 DDD에 대해 공부하고 이를 정리하는 글을 적어보는 것이 좋겠다.
  DDD와 ORM에 대한 이해가 필요하다. 객체에 대해서 정리한 개념도 필요하고...

참고 사이트 : http://aeternum.egloos.com/category/Domain-Driven%20Design

+ Recent posts