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

Chapter 02. The Evolutionary Architect - Governance and Leading from the Center

Techniques/Building Microservices 2019/01/12 19:14 용비
Governance and Leading from the Center
(센터에서의 거버넌스와 리딩(리더십))

아키텍트가 처리해야만 하는 부분에는 거버넌스가 있습니다. 거버넌스가 무엇을 의미합니까?
Control Objectives for Information and Related Technology (COBIT) (정보 및 관련 기술에 대한 제어 목표?)는 꽤 좋은 정의를 가지고 있습니다.

거버넌스는 이해관계자(stakeholder)의 요구, 조건, 옵션을 평가하여 기업의 목표(enterprise objective)가 달성될 수 있도록 보장합니다.
우선순위와 의사 결정을 통한 방향 설정, 동의된 방향 및 목표에 대한 성과와 컴플라이언스(법령 준수), 진행 상황을 모니터링합니다.
------ COBIT 5

거버넌스는 IT 포럼에서 여러 가지 사항에 적용될 수 있습니다.
아키텍트의 업무라고 생각하는 기술적인 거버넌스 측면에서만 중점을 두기 원합니다.
만약 아키텍트의 업무 중 하나가 기술적인 비전을 보장하는 것이라면, 거버넌스는 우리가 구축하는 것과 비전을 일치시키고, 필요하면 이 비전을 발전시키는 것입니다.

아키텍트는 많은 것들을 책임지고 있습니다.
아키텍트는 개발을 가이드할 수 있는 일련의 원칙들이 있는지, 이 원칙들이 조직의 전략과 일치하는지를 확인해야 합니다.
아키텍트는 이러한 원칙들이 개발자들을 비참하게 만드는 실무 실행절차들을 요구하지 않도록 확실히 해야 합니다.
아키텍트는 최신 새로운 기술을 파악하고, 언제 올바르게 절충(trade-offs)해야 하는지 알아야 합니다.
이것은 대단한 책임입니다.

또한 이 모든 것과 함께 사람들을 데리고 가야 합니다.
함께 일하는 동료들이 결정을 이해하며 일을 하고, 그것을 수행하게 하기 위해서입니다.

그리고 이미 언급했듯이, 의사 결정과 심지어 코드에 대한 영향을 이해하기 위해서 팀과 함께 약간의 시간을 보내는 것이 필요합니다.

힘든 주문인가요?
전혀 아닙니다.

그러나 이것을 홀로 해서는 안 된다는 견해에 대해서 확고합니다.
제대로 기능을 수행하는 거버넌스 그룹은 함께 작업을 공유하고 비전을 형성할 수 있습니다.
일반적으로, 거버넌스는 그룹 활동입니다.

규모가 작은 팀과의 비공식적인 채팅이거나 더 큰 범위의 정식 그룹 멤버십을 가진 더 구조화된 정규 미팅일 수도 있습니다.
이것이 우리가 앞에서 다룬 원칙들이 필요에 따라 논의되고, 변경되어야 한다는 것에 대해서 내가 생각한 것입니다.
이 그룹은 기술자에 의해 주도되어야 하고, 지배적인 업무를 수행하는 사람들로 주로 구성되어야 합니다.

이 그룹은 또한 기술 위험에 대해 추적하고 관리해야 합니다.

내가 가장 좋아하는 모델은 아키텍트가 그룹의 의장을 맡는 것이지만, 대부분의 그룹은 최소한 각 팀을 리드하는 각 딜리버리 팀(delivery team)의 기술자들로 이루어진 것입니다.
아키텍트는 그룹이 동작하는지 확인할 필요가 있습니다만, 그룹 전체가 거버넌스를 담당해야 합니다.
이것은 부하를 공유하고, 높은 수준의 승인(high level buy-in)을 보장합니다.
또한 팀에서 그룹으로 정보가 자유롭게 흘러가게 하고, 결과적으로 의사 결정이 훨씬 더 현명하게 이루어지고, 많이 알게 됩니다.

가끔, 그룹은 아키텍트가 동의하지 않는 의사 결정을 내릴 수 있습니다.
이 시점에서 아키텍트는 무엇을 해야 할까요?
전에 이 직책에 있었기 때문에, 이것이야말로 직면할 수 있는 가장 어려운 상황 중 하나라고 말해줄 수 있습니다.

종종, 나는 그룹 결정과 함께 가야하는 접근 방식을 택합니다.
사람들을 확신시키는데 최선을 다했다고 생각하지만, 궁극적으로 충분히 확신을 주지 못했습니다.
그룹은 종종 개인보다 훨씬 현명합니다. 그리고 나는 한번 이상 잘못했습니다.

그룹이 결정을 내리도록 공간이 주어지고 궁극적으로 무시되는 것에 대해서 어떻게 권한을 빼앗을 수 있는지 상상해 보십시오.
그러나 가끔 나는 그룹을 배제했습니다. 왜? 언제 그랬을까요?
라인(line)을 어떻게 선택합니까?
아이들에게 자전거를 타는 법을 가르치는 것에 대해서 생각해 보십시오.
여러분이 그들을 위해서 탈 수는 없습니다.

여러분은 아이들이 흔들리는 것을 보지만, 만약 여러분이 아이들이 떨어질 것처럼 보일 때마다 매번 개입했다면, 아이들은 결코 배우지 못하고, 어떤 경우에는 여러분이 그럴 것이라고 생각하는 것보다 훨씬 덜 넘어집니다.
그러나 만약 차가 다니는 방향으로 방향을 바꾸거나, 근처의 오리 연못으로 향한다면, 여러분이 개입해야 합니다.

마찬가지로 아키텍트로서 비유적으로 여러분의 팀이 오리 연못으로 방향을 잡고 있을 때, 확고한 이해력을 가지고 있어야 합니다.
또한, 심지어 여러분 자신이 옳다는 것을 알고 있고, 팀을 지배하고 있다면, 이것이 여러분의 지위를 손상시키고, 팀이 말을 하지 않는다고 느끼게 만들 수 있음을 깨달아야만 합니다.

때로는 올바른 일은 여러분이 동의하지 않은 결정에 따르는 것입니다.
이것을 언제 해야 하는지, 언제 하지 않아야 하는지를 아는 것은 어려운 일이지만, 때때로 중요합니다.
TAG , , ,
받은 트랙백이 없고, 댓글이 없습니다.

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

◀ 이전페이지 1 ... 21 22 23 24 25 26 27 28 29 ... 216 다음페이지 ▶