'Techniques'에 해당되는 글 17건

  1. 2019/01/29 용비 Eric-Evans DDD - Ch 04. Isolating the Domain
  2. 2019/01/28 용비 Eric-Evans DDD - Ch 03. Binding Model and Implementation
  3. 2019/01/28 용비 Eric-Evans DDD - Ch 02. Communication and the Use of Language
  4. 2019/01/28 용비 Eric-Evans DDD - Ch 01. Crunching Knowledge
  5. 2019/01/12 용비 Chapter 02. The Evolutionary Architect - Building a Team
◀ 이전페이지 1 2 3 4 다음페이지 ▶

Eric-Evans DDD - Ch 04. Isolating the Domain

Techniques/Domain-Driven Design 2019/01/29 17:15 용비

Part II: The Building Blocks of a Model-Driven Design


어지러운 현실에도 불구하고, 소프트웨어 구현을 명확하게 유지하고, 모델에 발맞추는 것은 모델링과 설계에 있어서 모범 사례(best practice)를 적용해야만 한다.
Domain-driven design은 어떤 전통적인 아이디어에서 강조하는 바를 바꾼다.

Chapter Four. Isolating the Domain


비록, 그 중요도가 크기와 균형이 맞지 않더라도, 특히 도메인에서 문제를 해결하는 소프트웨어의 일부분은 일반적으로 단지 전체 소프트웨어 시스템의 작은 부분으로 여겨진다.

Layered Architecture

Object-Oriented Program에서 UI, Database, 다른 Code는 종종 Business Object에 직접적으로 쓰여 진다. 추가적인 Business Logic은 UI Widget이나 Data기반 스크립트에 동작하도록 포함된다(embedded). 단기적으로 동작하도록 하는 가장 쉬운 방법이기 때문에 이런 경우가 발생하게 된다.

Domain과 연관된 Code는 많은 양의 다른 Code를 통해서 확산되고, 극도로 그것을 보거나 추론하기가 어렵게 된다. UI를 피상적으로 변경하는 것은 실제로 Business Logic을 변경하는 것이다. Business Rule을 변경하기 위해서는 UI Code, Database Code, 혹은 다른 프로그램 요소들을 세밀하게 추적해야 한다. 일관성있게 Model-Driven Object를 구현하는 것은 비현실적이다. 자동화된 테스트는 어색하다. 개별 Activity에 포함된 모든 기술과 로직으로 인해 프로그램은 매우 단순하게 유지되어야 하고, 그렇지 않은 경우 이해하는 것이 불가능하다.

소프트웨어 시스템을 여러 가지 방법으로 나눌 수 있다. 그러나 경험과 협약으로 인해 산업계에서는 Layered Architecture로 수렴하고 있다. 대부분의 개발자들이 이해하기 쉽기 때문이다.

필수적인 원칙은 레이어의 모든 요소는 동일한 레이어의 다른 요소나 "아래에 있는" 레이어 요소에만 의존한다는 것이다.

위로 향하는 커뮤니케이션은 나중에 간략하게 설명할 간접적인 메커니즘을 통과해야 한다.

레이어의 가치는 각각의 레이어가 컴퓨터 프로그램의 특별한 측면을 다룬다는 것이다.
물론, 가장 중요한 응집력있는 설계 측면을 격리하는 레이어를 선택하는 것이 중요하다.

복잡한 프로그램을 레이어로 나눈다. 응집력 있고, 아래에 있는 레이어에만 의존하는 각 레이어를 디자인하고 개발한다. 표준 아키텍처 패턴을 따라 위에 있는 레이어와 느슨한 결합을 제공하고, 하나의 레이어에서 도메인 모델과 관련된 모든 코드를 집중화하고, User Interface, Application, Infrastructure Code와 격리한다. 도메인 객체는 자체를 표시하고, 저장하고, Application Task를 관리하는 등등의 책임이 없고, 도메인 모델을 표현하는 것에만 집중할 수 있다. 이를 통해 모델은 필수적인 비즈니스 지식을 포작하고, 동작하도록 풍부하고 명확하게 진화할 수 있다.

도메인 레이어를 Infrastructure와 User Interface로부터 분리하는 것은 각 레이어를 명확하게 설계할 수 있게 한다. 격리된 레이어는 각 레이어별로 다른 요구사항과 비율로 진화할 수 있기 때문에 유지보수에 덜 비싸다. 또한, 이러한 분리는 커뮤니케이션 Overhead를 최소화하고, 성능을 개선하기 위해서 다른 레이어에 다른 서버나 클라이언트를 유연하게 위치시킬 수 있기 때문에 분산 시스템에서 배포에 도움이 된다.

Relating the Layers

레이어는 한 방향에 대한 의존성을 가지도록 느슨하게 연결되어야 한다. 위에 있는 레이어는 Public Interface를 단도직입적으로 호출하여 (최소한 일시적으로) 참조를 가지고 아래에 있는 레이어 요소를 사용하거나 다룰 수 있고, 일반적으로 전통적인 상호작용의 수단을 사용할 수 있다.

하지만, 하위에 있는 Object는 (쿼리에 대한 직접적인 응답으로) 위와 커뮤니케이션할 때 콜백이나 Observer와 같은 연결된 레이어에 댛나 아키텍처 패턴을 그리는 다른 메커니즘이 필요하다.

UI와 어플리케이션, 도메인 레이어를 연결하는 할아버지격 패턴은 MVC(Model-View-Controller) 패턴이다.

Architectural Frameworks

많은 Infrastructure의 요구사항을 통합하는 Framework는 종종 Framework 클래스의 하위 클래스나 구조화된 메소드 시그니처(method signature)와 같은 매우 특별한 방식으로 다른 레이어들을 구현해야 할 필요가 있다.
최고의 Architectural Framework는 복잡한 기술 문제를 해결하는 동시에 도메인 개발자는 모델을 표현하는데 집중할 수 있다.
하지만, Framework는 도메인 설계 선택을 제한하는 너무 많은 가정을 만들거나 구현이 너무 무거워서 개발이 느려지게 함으로써 쉽게 방해가 될 수 있다.
일반적으로는 Architectural Framework의 일부가 필요하다. (때때로 팀에서는 잘 제공하지 않는 Framework를 선택한다.)

Framework를 적용할 때, 팀은 도메인 모델을 표현하고 중요한 문제들을 해결하는데 사용하는 구현을 작성하는 것과 같은 목표에 중점을 두어야 한다.
팀은 비록 Framework의 모든 기능을 사용하지는 않더라도 그러한 목적에 Framework를 사용할 방법을 찾아야만 한다.
예를 들면, 초기 J2EE 어플리케이션은 종종 "Entity Bean"으로 모든 도메인 객체를 구현했다.
이러한 접근 방식은 성능과 개발 속도를 모두 저하시켰다.
대신에, 현재의 가장 좋은 사례(best practice)는 더 큰 grain object에 J2EE Framework를 사용하고, 일반적인(generic) Java Object로 대부분의 비즈니스 로직을 구현하는 것이다.
Framework의 많은 단점은 두루두루 적용되는 솔루션을 찾지 않고도 어려운 문제를 해결하기 위해서 선택적으로 적용함으로써 피할 수 있다.
Framework의 가장 가치있는 기능을 의도적으로 적용하면, 구현과 Framework의 결합이 감소하고, 이후 설계 의사결정에 유연성을 부여할 수 있다.

더 중요한 것은, 현재 많이 사용하는 Framework가 얼마나 복잡한지를 고려하면, 이러한 미니멀리즘(최소한의 표현주의)은 비즈니스 객체를 읽고 표현력 있게 유지하는데 도움이 된다.
Architectural Framework와 다른 도구들은 계속 발전할 것이다.
더 새로운 Framework는 어플리케이션의 기술적 측면을 점점 더 많이 자동화하거나 사전에 미리 만들것이다.

만약 이것이 올바르게 완료되면, 어플리케이션 개발자는 핵심 비즈니스 문제를 모델링하는데 시간을 집중하고, 생산성과 품질을 크게 향상시킬 것이다.
하지만, 우리가 이런 방향으로 나아갈 때, 기술적인 솔루션에 대한 열정을 경계해야 한다. 정교한 Framework는 또한 어플리케이션 개발자들을 구속할 수도 있다.

The Domain Layer Is Where the Model Lives

Layered Architecture는 다양한 레이어링 스키마 하에서 오늘날 대부분의 시스템에서 사용되고 있다. 또한, 많은 개발 스타일이 레이어링을 통해서 유익함을 얻을 수 있다.
하지만, Domain-Driven Design에서는 하나의 특정한 레이어만 존재하면 된다.

Domain Model은 개념들의 집합이다. "Domain Layer"는 모델과 직접적으로 관련되어 있는 모든 설계 요소들의 표현이다.
설계와 비즈니스 로직의 구현은 Domain Layer를 구성하고 있다. MODEL-DRIVEN DESIGN에서 Domain Layer를 구성하고 있는 소프트웨어는 모델 개념을 반영하고 있다.
도메인 로직이 프로그램의 다른 관심사와 섞여 있을 때, 연관성을 달성하는 것은 실용적이지 않다. 도메인 구현을 격리하는 것은 Domain-Driven Design에서 전제 조건이다.

The Smart UI "Anti-Pattern"

만약 단순한 프로젝트를 수행하는 정교하지 않은 팀에서 Layered Architecture로 Model-Driven Design을 시도하기로 결정하면, 어려운 학습 곡선(learning curve)에 직면하게 될 것이다.
팀 구성원들은 복잡한 새로운 기술을 숙달해야 하고, 객체 모델링 학습 프로세스로 휘청거려야 한다. (이 책의 도움을 받더라도 도전적이다.)
Infrastructure와 Layer 관리의 오버헤드로 인해 매우 단순한 작업이 더 오래 걸린다.
간단한 프로젝트에는 짧은 시간대와 겸손한 기대가 있다. 팀에 배정된 과제를 완료하기 전에 접근 방식의 흥미로운 가능성을 훨씬 덜 설명하기 때문에 프로젝트는 취소될 것이다.

심지어 팀에 더 많은 시간이 주어지더라도, 팀 구성원들은 전문가의 도움없이 기술을 마스터하는 것에 실패할 것이다.
그리고 결국, 이러한 도전을 극복한다면, 간단한 시스템을 만들어낼 것이다.
풍부한 기능은 결코 평가조차 받지 못했다.

Domain-Driven Design은 야심찬 프로젝트에 가장 적합하고, 강력한 skill을 필요로 한다. 모든 프로젝트가 야심차지도 않고, 모든 프로젝트 팀이 그러한 skill을 발휘하지도 않는다.

따라서, 모든 비즈니스 로직을 User Interface에 배치한다.
어플리케이션을 작은 기능으로 잘라서 비즈니스 규칙을 해당 기능에 포함시켜 별도의 User Interface로 구현한다.
관계형 데이터베이스를 데이터 공유 저장소로 사용한다.
자동화된 UI 빌드 및 이용 가능한 시각화 프로그래밍 도구를 사용하라.

TAG ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/823

Eric-Evans DDD - Ch 03. Binding Model and Implementation

Techniques/Domain-Driven Design 2019/01/28 16:49 용비

Binding Model and Implementation

(모델과 구현의 결합)

개발자가 응용 프로그램을 구현하기 시작했을 때, 인간 분석가가 탐색할 수 있지만 연관성의 얽힘이 트랜잭션 무결성으로 조작될 수 있는 저장 가능하고, 검색 가능한 단위로 변환되지 않았음을 빠르게 발견했다.

이 프로젝트는 객체 데이터베이스를 사용하고 있었기 때문에 개발자는 객체를 관계형 테이블로 맵핑해야 하는 어려움에 직면할 필요가 없었다. 기본적인 수준에서 모델은 구현 지침을 제공하지 않았다.

모델이 "완벽"했기 때문에, 기술 분석가와 비즈니스 전문가 사이에 광범위한 협업의 결과로, 개발자들은 개념 기반 객체가 설계의 기초가 될 수 없다는 결론에 도달했다. 그래서 개발자들은 ad hoc design(즉석 설계)을 개발하기 시작했다. 그 디자인은 데이터 저장을 위해서 약간의 동일한 클래스 이름(class names)과 속성(attributes)을 사용했지만, 기존 모델이나 다른 모델을 기반으로 하지 않았다.

프로젝트는 도메인 모델을 가졌지만, 직접적으로 실행중인 소프트웨어 개발에 도움이 되지 않는다면, 종이상의 모델이 무엇이 좋은가?

코드를 밑에 있는 모델과 밀접하게 연관시키는 것은 코드에 의미를 주고, 모델을 적합하게 만든다.
원인이 무엇이건 간에, 설계의 기초에서 개념이 결여된 소프트웨어는 기껏해야 동작을 설명하지 않고 유용한 어떤 것을 행하는 메커니즘에 불과하다.

설계, 혹은 설계의 일부 중심 부분이 도메인 모델과 맵핑되지 않으면, 모델은 거의 가치가 없고 소프트웨어의 정확성이 의심된다. 동시에, 모델과 설계 기능 사이에 복잡한 맵핑이 이해하기 어렵고, 실제로 디자인 변경에 따라 유지관리가 불가능하다.
분석과 디자인 사이에 치명적인 격차가 발생하기 때문에 각 활동에서 얻은 통찰력은 다른 활동으로 유입되지 않는다.

Model-Driven Design은 분석 모델과 디자인의 이분법을 폐지하고, 두가지 목적을 모두 제공하는 단일 모델을 찾는다. 순수하게 기술적인 문제를 제외하면, 디자인의 개별 객체는 모델을 설명하는 개념적인 역할을 수행한다.
이것은 두 가지 다른 목표를 달성해야 하기 때문에 선택한 모델을 더 많이 요구한다.

모델이 구현에 대해 현실적이지 않거나 도메인의 주요 개념에 대해 충실하게 표현하지 못하면 새로운 것을 찾아야만 한다. 도멜링과 디자인 과정은 하나의 반복되는 고리(single iternative loop)가 된다.

매우 문자 그대로의 방식으로 도메인 모델을 반영하기 위해서 소프트웨어 시스템의 일부를 디자인하므로 맵핑은 명확해야 한다. 모델을 재방문하여 소프트웨어에 더 자연스럽게 구현되게 수정하라. 심지어 도메인에 대한 더 깊은 인사이트(insight)를 반영하도록 할 때에도 마찬가지이다.

강력한 Ubiquitous Language를 지원하는 것 이외에도 두 가지 목적을 모두 제공하는 단일 모델을 요구하라.

설계에 사용된 모델과 용어로 기본적인 책임(responsibility) 할당을 그려라. 코드는 모델의 표현이므로, 코드의 변경은 모델을 변경하게 될 것이다. 따라서 그 효과는 프로젝트의 나머지 활동에 영향을 미친다.

모델에 구현을 밀접하게 묶기 위해서는 일반적으로 OOP(Object-Oriented Programming)와 같은 모델링 패러다임을 지원하는 소프트웨어 개발 도구와 언어를 필요로 한다.

단일 모델(single model)은 설계가 신중하게 고려된 모델의 직접적인 파생물이기 때문에 오류 가능성을 줄여 준다.
설계와 코드 그 자체에서도 모델의 의사소통 능력을 가지고 있다.

코드 작성하는 사람이 모델에 대한 책임감을 느끼지 않는다면, 혹은 어떻게 어플리케이션에서 모델이 동작하도록 하는지를 이해하지 못한다면, 모델은 소프트웨어와 아무런 관련이 없다. 개발자가 코드 변경이 모델을 변경하는 것을 깨닫지 못한다면, 리팩토링은 모델을 강화하기보다 약화시킬 것이다. 모델러가 구현 프로세스와 분리되어 있는 동안, 구현에 있어서 제약 사항에 대한 느낌을 결코 얻을 수 없거나 빨리 잃어버릴 것이다. Model-Driven Design의 기본적인 제약 사항-모델이 구현을 효과적으로 지원하고, 핵심 도메인 지식을 추상화한다는 것-은 반만 이루어지게 되고, 모델의 결과는 비현실적이 될 것이다. 마지막으로 업무의 분리가 Model-Driven Design 코딩의 미묘함을 전달하는 협업을 방해한다면, 경험있는 설계자의 지식과 스킬이 다른 개발자들에게 전달되지 않을 것이다.

실무 모델러(hands-on modeler)가 필요하다는 것은 팀 구성원이 특별한 역할을 할 수 없다는 것을 의미하는 것은 아니다. 모든 Agile 프로세스에서, Extreme Programming을 포함하여, 팀 구성원들의 역할을 정의하고, 다른 일상적인 전문화는 일반적으로 나타난다. 문제는 Model-Driven Design에서 밀접하게 연관되어 있는 모델링과 구현을 2개의 업무로 분리할 때 발생한다.

모든 설계에 있어서 효과는 잘 나누어진 설계(fine-grained design)와 구현 의사 결정의 균등함과 일관성에 매우 민감하다. Model-Driven Design과 함께, 코드의 일부분은 모델을 표현하고, 코드의 변경은 모델을 변경한다. 다른 사람이 좋아하든, 그렇지 않든지 간에, 프로그래머는 모델러이다. 따라서, 프로그래머가 훌륭한 모델링 업무를 하도록 프로젝트를 설정하는 것이 더 좋다.

프로젝트에서 주요 역할이 무엇이건 간에, 모델에 기여하는 어떤 기술적인 사람이라도 코드를 다루는데 시간을 보내야 한다. 코드를 변경하는 사람이 누구이건 간에 코드를 통해 모델을 표현하는 방법을 배워야 한다. 모든 개발자는 모델에 대한 어느 수준의 논의에 포함되어야 하고, 도메인 전문가와 함께 해야 한다. 다른 방식으로 기여하는 사람들은 Ubiquitous Language를 통해 모델에 대한 아이디어를 동적으로 교환하여 코드를 다루는 사람으로 의식적으로 참여해야 한다.

Domain-Driven Design은 어플리케이션의 문제를 해결하기 위해 모델이 동적하도록 한다.
Model-Driven Design은 모델과 구현을 긴밀하게 연결한다.
Ubiquitous Language는 모든 정보가 개발자와 도메인 전문가, 소프트웨어 사이에 흐르게 하는 채널이다.
TAG ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/822

Eric-Evans DDD - Ch 02. Communication and the Use of Language

Techniques/Domain-Driven Design 2019/01/28 16:47 용비

Ch 2. Communication and the Use of Language


도메인 모델은 소프트웨어 프로젝트에서 공통 언어의 핵심이 될 수 있다. 모델은 프로젝트에 참여한 사람들의 머리속에 구축되어 있는 도메인 인사이트를 반영한 용어와 관계로 이루어진 개념들의 집합이다.
도메인 전문가는 소프트웨어 개발에 대한 기술적인 용어에 대한 이해는 제한되어 있지만, 그들만의 필드에 있는 용어를 사용한다.
반대로, 개발자들은 도메인 전문가들의 언어와는 전혀 연결되지 않는, 묘사적이고 기능적인 용어로 시스템을 이해하고 논의할 것이다.
또는 개발자들은 그들의 설계를 지원하는 추상화를 만들어 낼지도 모르지만, 도메인 전문가는 전혀 이해하지 못한다.

이와같은 언어학적인 분리로 인해서 도메인 전문가들은 그들의 요구사항을 모호하게 이야기하고, 개발자들은 그들에게 새로운 도메인을 이해하기 위해서 모호하게 이해한 상태에서 싸우게 된다. 팀 내 일부 멤버만이 두가지 언어를 다룰 수 있지만, 정보 흐름의 병목점이 되고 불완전하게 번역하게 된다.

공통의 언어가 없는 프로젝트에서 갭라자들은 도메인 전문가를 위해서 번역을 해야만 한다. 도메인 전문가들은 개발자들과 다른 도메인 전문가들 사이에서 번역을 해야만 한다. 심지어 개발자들도 서로 간에 번역을 한다. 번역은 모델의 개념을 뒤죽박죽으로 만들고, 코드 리팩토링을 파괴적으로 이끈다.

Ubiquitous Language라는 단어는 클래스 이름과 주요한 동작을 포함하고 있다. Language는 모델을 명확하게 하는 규칙을 논의하는 용어를 포함한다.

모델 기반 언어는 시스템의 형상 뿐만 아니라 태스크와 기능을 설명하기 위해서 개발자들 사이에 사용되어야 한다. 동일한 모델은 개발자들과 도메인 전문가들이 서로 커뮤니케이션하기 위한 언어로 제공되어야 한다. 그리고 도메인 전문가들 사이에서 요구사항, 개발 계획, 기능들에 대해서 커뮤이케이션하기 위해서도 필요하다.

용어가 변경되면, 도메인 모델이 변경되고, 코드 상에서 클래스 다이어그램과 클래스 이름 변경, 메소드 변경이 일어난다.

모델 기반 언어를 넘치게 사용하여 흐를 때까지 만족되지 않는 경우에는 복잡한 아이디어를 표현하기 위해 간단한 엘리먼트들을 결합하여 모델이 완전해지고, 이해가능해지도록 한다.

따라서, 모델을 언어의 백본으로 사용하라.
팀 내 커뮤이케이션과 코드 내에서 해당 언어를 광범위하게 사용하도록 약속하라. 다이어그램, 코드 작성, 특히 대화에 동일한 언어를 사용하라.
Ubiquitous Language의 변경은 모델의 변경이라는 것을 명심해야 한다.


Ubiquitous Language는 코드상에는 나타나지 않는 디자인 측면의 주요 소통 수단이다.
Bounded Context는 다른 시스템과 모델의 관계를 정의하는 것이다.
모델과 디자인에는 다른 패턴들도 적용될 수 있다.

시스템에 대해서 이야기할 때 모델로 하라. 모델 요소와 상호작용을 사용하고, 모델에서 허용된 방법으로 개념을 조합하여 시나리오를 설명하라. 말하고자 하는 것을 더 쉽게 이야기하는 방법을 찾고, 그 새로운 아이디어를 다이어그램과 코드에 다시 반영하라.
(Business Logic이나 flow를 최적화하고, 그것을 모델링한 다음, 코드로 반영)

UML 다이어그램이나 가장 많이 사용하는 클래스 다이어그램, 객체간 상호 작용 다이어그램을 이용하여 커뮤니케이션한다.

문제는 사람들이 UML을 통해서 전체 모델이나 디자인을 전달하도록 강요받는다고 느낄 때 발생한다.
다이어그램에 있는 많은 객체 모델은 너무 완벽하고, 동시에 너무 많이 생략한다. 너무 완벽해서 사람들은 모든 객체에 대 코드를 모델링 도구로 옮겨야만 한다고 생각한다.

모든 것이 상세하면, 아무도 나무만 보고 숲을 볼 수 없다.
하지만, 모든 세부사항에도 불구하고, Attribute와 Relationship은 객체 모델 스토리의 절반에 불과하다.
객체의 동작과 제약사항들은 쉽게 설명하되지 않는다. 객체간 상호동작 다이어그램은 디자인에서 까다로운 hotspot을 설명할 수 있지만, 상호작용이 많아지면 그런 방법으로는 보일 수 없다. 다이어그램을 만드는 사람이나, 그것을 읽는 사람이나 일이 너무 많아진다.
상호작용 다이어그램은 모델의 뒤에서 목적을 암시할 뿐이다.

모델이 다이어그램이 아니라는 것을 항상 기억하라. 다이어그램의 목적은 커뮤니케이션을 돕고, 모델을 설명하기 위한 것이다. 코드는 설계에 대한 세부사항의 Repository로서 제공될 수 있다. 잘 작성된 Java는 그 자체로 UML처럼 표현적이다.

Documents Should Complement Code and Speech
(문서는 코드와 말을 보완해야 한다.)

각 Agile 프로세스는 문서에 대한 자체 철학을 가지고 있다. Extreme Programming(Agile 방법론 중 하나)은 추가 디자인 문서를 전혀 사용하지 않는 것을 지지한다. 그리고 코드 그 자체로만 이야기한다. 실행중인 코드는 다른 문서와는 달리 거짓말을 하지 않는다. 실행중인 코드는 모호하지도 않다.

Extreme Programming은 프로그램의 active element(활성 요소)와 실행가능한 테스트에만 전적으로 집중한다.
하지만, 코드가 설계 문서가 되기에는 제한점이 존재한다. 세부사항으로 인해 독자를 압도할 수 있다. 동작이 모호하지 않지만, 분명하다는 것을 의미하지는 않는다. 동작의 뒤에 있는 의미는 전달되기 어려울 수 있다. 다시 말하자면, 코드를 통한 전적인 문서화는 포괄적인 UML 다이어그램을 사용함으로써 발생하는 기본적인 문제와 동일하다.

다른 문서들은 large-scale 구조에 대한 insight를 주기 위해서, 그리고 핵심 element에 대한 주의를 집중하기 위해 의미를 비출 필요가 있다.

Documents Should Work for a Living and Stay Current
(문서는 먹고 살기 위해서 일해야 하며, 현재 상태를 유지해야 한다.)

저자는 모델링 문서 작업을 할 때, 작고 주의 깊게 선택된 모델의 하위집합, 그리고 그 하위집합의 주위에 텍스트로 다이어그램을 그린다.
자연어로 할 수 있는 한, 클래스와 클래스가 가지 책임, 의미하는 맥락에서 프레임을 글자로 정의한다.
그러나 다이어그램은 개념을 객체 모델로 공식화하고 모델로 페어링할 때, 이루어진 몇 가지 선택을 보여준다.
이러한 다이어그램들은 대충 그린-심지어 손으로 그린- 어떤 것이 될 수 있다. 게다가 노력을 줄이기 위해서 손으로 그린 다이어그램은 격식이 없고 임시적으로 생각하는 장점이 있다. 일반적으로 우리의 모델 이이디어를 정말로 나타내기 때문에 커뮤니케이션에 좋다.

설계 문서의 가장 큰 가치는 모델의 개념을 설명하고, 코드의 세부 사항을 아는데 도움이 되고, 모델 사용에 대한 의도하는 스타일을 알게 하는 것이다.
문서는 프로젝트 activity에 포함되어야 한다. 이것을 판단하는 가장 쉬운 방법은 Ubiquitous Language로 문서의 상호작용을 관찰하는 것이다. 문서가 (지금) 프로젝트에서 사람들이 말하는 언어로 작성되었는가? 문서는 코드에 포함된 언어로 작성되었는가?


Explanatory Models
(설명하는 모델)

이 책의 요지는 하나의 모델이 구현, 설계, 팀 커뮤니케이션의 기반이 되어야 한다는 것이다. 이러한 여러 목적에 대해 여러 개의 모델을 가지는 것은 위험을 제기한다.
모델은 또한 도메인에 대해 가르치기 위한 교육 목적으로써 가치를 가질 수 있다. 설게를 유도하는 모델은 도메인에 대한 하나의 뷰이지만, 다른 뷰로는 단지 교육적인 도구로 사용되어 배우고자 하는 목적을 가질 수 있다. 이러한 목적으로 사람들은 소프트웨어 디자인과 무관한 다른 모델 종류를 전달하는 그림이나 글자를 사용할 수 있다.

Explanatory Model들은 특정 주제에 딱 맞는 훨씬 더 많은 커뮤니케이션 스타일을 만들기 위한 자유를 제공한다.
TAG ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/821

Eric-Evans DDD - Ch 01. Crunching Knowledge

Techniques/Domain-Driven Design 2019/01/28 16:46 용비
Eric Evans이 2003년도에 책으로 출판한 Domain-Driven Design을 요약/번역했습니다.

모든 모델은 실제적인 측면이나 흥미를 가지고 있는 아이디어를 설명하는 것이다.
모델은 단순하다.
모델은 가까이 있는 문제를 적절하게 해결하기 위한 측면을 추상화하여 실상에 대해 설명하고, 관련없는 세부 사항에 대해서는 무시한다.
도메인 모델은 특정 다이어그램이 아니다. 도메인 전문가의 머리속에 있는 지식이 아니라, 엄밀하게 구성된 지식의 선택적인 추상화이다. 다이어그램으로 모델을 설명하고 커뮤니케이션할 수 있다.

The Heart of Software
소프트웨어의 핵심은 사용자가 원하는 도메인 관련 문제들을 해결하는 능력이다.
다른 모든 특징들은 기본적인 목적을 지원하는 것이다.
도메인이 복잡할수록, 어려운 작업이고, 재능있고 능력있는 사람들의 집중화된 노력이 필요하다.
개발자들은 비즈니스에 대한 지식을 공부하기 위해서 스스로 도메인에 푹 젖어들어야 한다.
또한 모델링 기술을 연마하고, 도메인 디자인을 마스터해야 한다.
하지만, 대부분의 소프트웨어 프로젝트에서 이것은 우선순위가 아니다.
대부분의 재능있는 개발자들은 그들이 작업할 특정 도메인에 대해 배우는데 흥미가 없다. 또한, 도메인 모델링 스킬을 확장시키기 위해서 훨씬 덜 몰입한다.

Ch 1. Crunching Knowledge (지식을 고속처리하기)


Ingredients of Effective Modeling
(효과적인 모델링을 위한 성분)

1. 모델과 구현의 결합 (Binding the model and the implementation)
2. 모델 기반 언어로 구축 (Cultivating a language based on model)
3. 지식이 풍부한 모델 개발 (Developing a knowledge-rich model)
4. 모델 정제 (Distilling the model)
5. 브레인스토밍과 실험하기(Brainstorming and experimenting)

Knowledge Crunching (지식 고속 처리)
금융 분석가는 숫자를 고속으로 처리한다.
효과적인 도메인 모델러는 지식을 고속으로 처리하는 사람이다.
지식의 고속처리는 혼자 하는 활동이 아니다. 개발자와 도메인 전문가로 이루어진 팀이 협업을 하고, 일반적으로 개발자가 리딩한다.
그들은 함께 유용한 형태로 처리하도록 정보에 대한 그림을 그린다.
밑그림은 도메인 전문가의 마음과 기존의 시스템 사용자, 연관된 레가시 시스템에 대한 선행경험이 있는 기술팀이나 같은 도메인의 또다른 프로젝트에서 나온다.

훌륭한 개발자는 모델을 추상화하여 개발하므로 더 많은 일을 할 수 있다. 그러나 도메인 전문가와의 협업없이 기술적인 설정에만 머무른다면, 개념이 모호하다.
지식의 천박함으로 인해 소프트웨어는 기본적인 작업만 하고 도메인 전문가가 생각하고 기대하는 바는 결여되게 된다.

TAG ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/820

Chapter 02. The Evolutionary Architect - Building a Team

Techniques/Building Microservices 2019/01/12 19:16 용비
Building a Team
(팀 구축)

시스템에 대한 기술적 비전을 책임지는 주요 핵심 인물이 되는 것, 그리고 그 비전을 실행하는 것을 확인하는 것은 기술적인 결정을 내리는 것에 관한 것만은 아닙니다.

그것은 여러분이 일을 하게 될 사람과 함께 일을 하는 사람입니다.

기술적 리더의 역할 중 많은 부분은 그들을 성장시키는데 도움이 되는 것입니다. - 비전을 스스로 이해하고, 비전을 구체화하고 구현하는데 능동적인 참여자가 될 수 있디록 보장하는 것입니다.

커리어 성장을 위해 여러분 주변 사람을 돕는 것은 여러 형태가 있을 수 있습니다. 대부분 이 책의 범위에서 벗어납니다. 그러나 마이크로서비스 아키텍처가 특히 관련이 있는 한가지 측면이 있습니다.

대규모의 모놀리틱 시스템(monolithic system)에서 사람들이 한발 더 나아가 뭔가를 소유할 기회가 줄어듭니다.
반면에 마이크로서비스에서는 독립적인 수명주기(lifecycle)을 가질 수 있는 여러 개의 자율적인 코드베이스를 가지고 있습니다.

더 많은 책임을 받아 들이기 전에 개별 서비스에 대한 소유권을 가지게 함으로써 한발 더 나아가게 돕는 것은 커리어 상의 목표를 달성할 수 있도록 돕고 동시에 누가 책임자가 되든지 부담을 덜어주는 굉장한 방법이 될 수 있습니다.

나는 위대한 소프트웨어는 위대한 사람들로부터 나온다는 것을 강하게 믿습니다.
평형 상태의 기술적인 측면에서만 걱정하고 있다면, 그림의 절반 이상을 놓치고 있는 것입니다.


Summary
(요약)

이 장을 요약하면, Evolutionary Architect의 핵심 책임에 대해서는 다음과 같이 요약할 수 있습니다.

Vision (비전)
여러분의 시스템이 고객과 조직의 요구사항을 만족시키는데 도움이 되는 시스템에 대한 명확하게 커뮤니케이션된 기술적 비전이 있는 확인하십시오.

Empathy (공감)
여러분의 결정이 고객과 동료에게 미치는 영향에 대해서 이해하십시오.

Collaboration (협업)
비전을 정의하고, 재정의하고, 실행하는데 도움이 되는 가능한 한 많은 상사와 동료를 끌어들이십시오.

Adaptability (적응성)
기술적 비전이 고객과 조직에서 요구하는 대로 변경되는지 확인하십시오.

Autonomy (자율)
팀의 표준화와 자율성 사이에서 올바른 균형을 찾으십시오.

Governance (거버넌스)
구현되고 있는 중인 시스템이 기술적 비전에 맞는지를 확인하십시오.

진화하는 아키텍트(evolutionary architect)는 이러한 위업의 달성이 끊임없는 균형잡힌 행동이라는 것을 이해하는 사람 중 한명입니다.

힘은 항상 여러분을 어떤 방향으로 Push하고 있습니다.
그리고 어디에서 뒤로 물러나야 하는지, 혹은 어디로 흐름을 가져가야 하는지를 이해하는 것은 흔히 단지 경험에서만 오는 것입니다.
그러나 우리를 변화로 밀어넣는 이런 모든 힘에 대한 가장 최악의 반응은 우리의 생각안에서 더 견고해 지거나 고정되는 것입니다.

이 장에서의 많은 조언은 모든 시스템 아키텍트에게 적용될 수 있지만, 마이크로서비스는 우리가 더 많은 결정을 내리게 합니다.
그러므로, 이러한 모든 trade-offs에 대해 균형을 더 잘 잡는 것이 필수적입니다.

다음 장에서는 마이크로서비스의 경계를 어떻게 찾는지에 대해 생각해보면서 아키텍트의 역할에 대한 새로운 인식에 대해서 알아볼 것입니다.
TAG , , ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/819

◀ 이전페이지 1 2 3 4 다음페이지 ▶