[JCO] 2번째 Track : 도메인주도 개발(DDD)

∘ 발표자 : 김민재, 이경진
∘ 발표내용 : 소프트웨어 중심에 존재하는 복잡성에 도전장을 내밀다
∘ 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