Skip to content

Latest commit

 

History

History
52 lines (43 loc) · 6.27 KB

[세윤]_1장-2장.md

File metadata and controls

52 lines (43 loc) · 6.27 KB

들어가기 전에

소프트 웨어란?

  • 현실 생활의 복잡함을 다루기 위한 도구
  • 목적을 위한 수단이며 그 목적은 실행적이고 실제적인것
  • 실용적이고 유용해야 한다.
  • 우리 삶의 특정 측면과 깊은 관계를 맺게 된다.

1장. 도메인 주도 설계란 무엇인가?

  • 현실 세계의 프로세스를 자동화하거나 비즈니스 문제를 해결하기 위해 개발된다.
  • 자동화된 비즈니스 프로세스나 현실 세계의 문제가 소프트웨어의 도메인이다.
  • 소프트웨어란 이 도메인으로부터 시작되고 때려야 뗄 수 없는 관계를 가지고 있음을 이해해야 한다.
  • 소프트웨어는 코드로 구성된다. 그러나 우리는 코드 작업 자체에 너무 많은 시간을 보내는 경향이 있고, 소프트웨어를 단순한 오브젝트와 메서드의 관점에서 보기도 한다.
  • 자동차 생산을 생각하면 자동화 된 생산 공정 노동자는 특정 부품에 전문가지만, 전체를 이해하기 어려울 것이다.
  • 좋은 소프트웨어를 만들기 위해서는 그 소프트웨어가 무엇에 관련된 것인지 알아야 한다.
  • 즉, 도메인을 알아야 하는데 도메인을 가장 잘 아는 사람은 누구일까? 은행을 예시로 들면 바로 은행 업무에 속해있는 사람들이다. 이걸 해당 분야의 전문가라고 한다면 소프트웨어를 만들기 위해서는 언제나 도메인으로 시작을 해야 한다.
  • 도메인을 모델링해야 하는데, 은행 업무를 모르는 사람도 단지 도메인 모델로 작성된 코드를 읽어 보기는 것만으로 은행 업무에 대해 많은 것을 배울 수 있어야 한다.
  • 도메인에 깊이 뿌리내리지 못한 소프트웨어는 향후 변화에 제대로 대응할 수 없다.
  • 그럼 하나의 도메인이란? 세상의 어떤 것이다. 이걸 추상화 하는 것이 중요하다.
  • 그럼 추상화란? 도메인을 표현한 모델로 도메인 모델은 특정한 다이어그램이 아니라 그 다이어그램이 전달하고자 하는 아이디어다. 전문가의 지식 그자체가 아니라 지식에서 선택적으로 추상화해 조직화 한것이라고 생각하면 된다. 다이어그램은 단순히 모델을 가시적으로 표현한 것뿐이다.
  • 그럼 모델은? 대상 도메인에 대한 내부적 표현일 뿐이다.
  • 도메인에 대한 우리의 모든 사고 활동은 모델로 통합된다.
  • 우리는 모델을 사용해서 도메인 전문가, 설계자와 개발자 들과 의사소통해야 한다.
  • 의사소통을 하기 위해서는 시각적인 도구나 글로 적어서 하는데 이때 중요한 게 언어이다.
  • 우리가 모델로 의사소통을 할 필요가 있는데 도메인의 특정 이슈를 서로 알리고 나눌 언어를 만들어야 한다.
  • 소프트웨어 설계는 집의 구조를 만드는 것처럼 큰 그림을 다루는 작업이다. 코드 설계는 어떤 벽에 그림을 걸지 정하는 것처럼 세부 사항에 관한 작업이다.
  • 좋은 코드 설계를 위해 여러모로 편리하게 쓰이는 디자인 패턴들이 있으며 필요할 때 이 패턴들을 적용해야 한다. 좋은 코딩 기법은 깔끔하고 유지보수하기에 좋은 코드를 만들어 내는 데 기여한다.
  • 몇가지 접근법이 있다.
    • 폭포수 설계 방법
    • 익스트림 프로그래밍 - 애자일
  • 이것을 적용하면 개발 프로세스가 도메인 복잡한 문제를 모델링하고 구현할 수 있는 능력이 유지 가능한 방식으로 획기적으로 높아진다. 도메인 주도 설계는 설계와 개발 방식을 연관지어 설계와 개발이 더 나은 해결책을 도출하는 데 어떻게 함께 작동할 수 있는지 보여준다. 좋은 설계는 개발을 가속화하고, 동시에 개발 프로세스에서 받는 피드백이 설계를 더욱 강화한다.

도메인 지식 쌓기

  • 당신과 도메인 전문가들은 이야기를 하고 있고, 서로 지식을 교환하는 중이다. 다신은 질문을 하기 시작하고, 그들은 대답한다.
  • 도메인의 필수 개념을 알아내도록 노력해라.
  • 소프트웨어 설계자의 분석적인 자세는 도메인 전문가들과 토의하는 도중에 도메인의 핵심 개념을 발굴해 내는 데 도움이 된다. 그리고 향후 대화의 기틀을 마련하는 데에도 좋다.
  • 즉, 소프트웨어 전문가와 도메인 전문가들은, 도메인 모델을 함께 만들어 낸다.
  • 결국 소프트웨어의 목적이란 현실 세계의 도메인 안에 있는 비즈니스 문제들을 해결하기 위한 것이기 때문이다. 따라서 그 도메인과 소프트웨어는 철저하게 혼합되어야 한다.

2장. 유비쿼터스 언어

공통 언어의 필요성

  • 의사소통 방식의 차이를 극복하려면 우리는 모델을 만들때, 모델에 대한 아이디어, 포함되어야 할 요소, 그것들을 어떻게 연결할 것인지, 어떤 것들이 관계가 있고 어떤 것들은 관계가 없는지와 같은 정보를 교환해야만 한다.
  • 도메인 주도 설계의 핵심 원칙은 모델 기반의 언어를 사용하는 것 이다. 모델은 소프트웨어와 도메인이 서로 교차하는 지점이기 때문에 모델 기반 언어를 사용하는 것이 가장 적절하다.
  • 이때 팀이 사용하는 모든 의사소통의 형식에 항상 이 언어가 사용되도록 확인하라. 이러한 관점에서 이 언어를 유비쿼터스 언어라 부른다.
  • 대안적인 모델을 표현하는 대안이 될 만한 표현들을 실험해 봄으로써 이러한 어려움을 해소할 수 있다. 이어서 새로운 모델에 부합하도록 클래스, 메서드, 모듈의 이름을 변경하여 코드를 리팩터링 하라. 항상 사용하는 단어의 의미에 서로 합의하는 식으로 혼란을 해소하라.
  • 또한 UML은 클래스와, 내부 속성 및 그 사이의 관계를 표현하는 데에는 매우 적합하지만, 클래스의 행동이나 제약 사항을 표현하기는 그리 쉽지 않다.
  • 모델의 부분 부분을 작은 다이어그램으로 구성하는 것도 권할 만한 의사소통 방법이다. 이러한 작은 다이어그램들은 몇 개의 클래스와 클래스 간의 관계로 이루어진다.