패턴 I 회에서는 아키텍처 시각화 패턴의 전체적인 구조와 구성되는 패턴들의 종류들을 간단히 소개하고, 아키텍처 시각화를 하기 전에 소프트웨어 시스템을 분석하기 위한 기본 요소들인 Domain Level Classifier Pattern과 Class Dependency Classifier Pattern에 대해서 살펴보았다.
2회에서는 시간에는 소프트웨어 시스템의 아키텍처 분석에 기본이 되는 다양한 Metric에 대한 설명을 올렸다.
이번 3회에서는 의존성을 관리하는 시각화 지표를 설명한다.
지난해 다양한 소프트웨어 아키텍팅 강의를 진행해 왔습니다. 아키텍처 설계 및 평가 기법, 그리고 부하테스트/ 성능 최적화에 대한 강의가 주를 이루었습니다. 아키텍처 설계 프로세스는 말그대로 진행은 하면 되지만, 결국 많은 설계 기법을 알지 못하면 좋은 설계를 하지 못하는 상황이 빈번하게 발생했습니다. 2022년에 다음과 같은 강좌 들을 진행했습니다. 강의를 하다보면서, 아직 많은 교재들이 디자인패턴에 지식이 머물러있고, 몇몇 […]
일전에 약속을 드렸던 것처럼 Fault Tolerance 패턴 자료를 공유드립니다. 고 가용성이라는 것이 서버쪽에서는 동일한 요소를 두개 주는 이중화라는 기법으로 확보가 가능하지만, 자동차나 프론트엔드, 모바일쪽에서는 이중화 전략을 쓰기에는 한계가 많습니다. 소프트웨어 아키텍처 설계 과정을 준비하면서 만든 자료입니다. 저 역시 많은 선배님들의 지식을 가지고 성장했던 것처럼, 이 자료가 많은 동료와 후배분 들에게 미약하나마 도움이 되었으며 합니다. pdf로 […]
제가 패턴학회에 이사회 맴버로 있고, 저에게 가르침과 영향을 많이 주신 두분이 계십니다. 한 분은 유연하면서도, 지혜로운 삶을 사는 자세를 가르쳐 주신 Linda Rising 이시고, 또 한분은 AT&T에서 네트워크 스위치 개발을 시작으로, 오랫동안 Fault Tolerant 패턴을 정리해 주신 Robert S. Hanmer 님입니다. Bob Hanmer 님은 요즘 외부 활동을 잠시 쉬고 계시지만 이 분의 여러가지 노력들을 아래와 […]
PLoP이 드디어 20주년을 맞이 했습니다.
20주년 행사인 만큼, 초기 패턴을 이끌었던 맴버들이 대거 참석한다는 것이고, 가장 먼저 PLoP 이 열렸던 성지인 Allerton Park에서 열립니다. 책에서 본 그곳에서 책에서나 보는 대가들과 만난다니 기쁘네요.
- Ralph Johnson
- Ward Cunningham
- Rebecca Wirfs_Brock
- Joseph Yoder
- Richard Gabriel
- Joshua Kerivsky
아실 분은 아시겠지만, 저랑 저희 스터디에 김지원 군이 PLoP을 이끄는 Hillside Group의 이사회 위원으로 2012년 부터 합류하게 되었습니다.
PLoP을 다닌지 5년만에 되었네요. 아시아 학회의 공동 의장이기도 하지만, 이로서 더 넓은 영향력을 얻게 되었습니다.
얼마전 이대엽님이 도메인 주도 설계 (Domain Driven Design) 라는 명서를 번역해 주셨습니다. 저 역시 구매를 했었고, DDD가 가져오는 철학이나 사상은 정말 훌룡합니다.
왜 이런 명서가 이제 번역될수 밖에 없는지 현실을 알고 있지만, 정말 슬픕니다.
POSA나 DDD와 같은 명서들은 번역을 한다는 것의 거의 희생에 가깝습니다.
사실 역자 입장 에서는 적절한 어휘 선정과, 국내 개발자의 시선에 맞게 레벨을 조정하기 위해 각주를 다는등 여러가지 노력이 필요합니다.
또한 책이 많이 팔릴지도 의문이고, 이미 읽을만한 분은 다 읽었다고 생각이 들고, 나의 안티를 양성하지 않을까 고민이 됩니다.
실례로, 몇몇 출판사를 통해 “명서를 왜 이렇게 번역했느냐?”라며 여러가지 공격을 당한 사례들을 종종 들었기에 쉽게 움직이지 못하는 것도 사실입니다.
이러한 상황에서도 DDD가 이 세상에 나오게 해주신 이 대엽님과 여러 고생해 주신 분들에게 감사를 드립니다.
다시 본론으로 돌아와 DDD는 고객과 개발자/아키텍트 간에 대화를 나눌수 있는 좋은 도구입니다.
패턴 계의 철학을 생각해 보면, 모든 상황에 만능인 솔루션은 없다. 단지 상황에 맞는 해결책이 있다는 것을 생각해 볼 필요가 있습니다. 그러기에 해당 Context들이 대부분 도메인과 밀접한 연관이 있고, DDD의 초안이 PLoP 에서 첫 데뷔를 했기 때문에 역시 그 본류는 패턴의 철학과 맞 닿아 있는 방법입니다.
그럼 DDD를 프로젝트에 적용하기 이전에, 고려해야 할 것들 이야기 해보고자 합니다. 어떠헌 프로세스, 툴들에게도 동일하게 적용된느 철학입니다. 맹목적인 추종보다 결국 상황에 맞는 솔루션이라는 것을 기억해 주셔야 됩니다.
PLoP 11 / SPLASH에 다녀오겠습니다. 갑자기 쌩뚱맞지만, 이제 저에게는 연례 행사가 되었답니다. 저의 성장에 큰 밑거름이 되준 PLoP에 다녀와서 많은 정보를 공유하겠습니다.
또한 이번 학회는 별로 외롭지 않은 것이 EVA팀의 김지원군 역시 회사 지원을 받아 같이 가게 되었습니다. 포스팅을 2배로 할수 있고, 곧 더 많은 정보를 전달해 드릴수 있어서 정말 기쁩니다. 전 아마 이 학회 다녀오면 몇일간은 잠을 못자며 정리하느라 보낼 수도 있습니다.
작년 2010년 PLoP에 다녀와서 남긴 포스트 입니다. 물론 더 있지만 굵직한 것 위주로 정리해 봤습니다. (PLoP 에 대한 더 많은 정보를 아시고 싶으시면, https://arload.wordpress.com/tag/plop/를 보시면 될듯 합니다.)
패턴계에서는 절대적으로 내려오는 한가지 격언이 있습니다.
Pattern isn’t an island. 패턴은 섬이 아니다.
패턴이라는 것은 크게는 Architecture을 결정하기도 하며, 그 밑에 Design을 결정하는 중요한 역할을 합니다. 즉 패턴간에 서로 깊은 연관성을 가진다는 것 입니다.
일전에 제가 다녀왔단 PLoP Bootcamp 포스트에서 Fault Tolerance 패턴의 저자인 Bob Hanmer가 Problem/Solution에서 언급한 패턴 언어를 참고하시기 바랍니다.
위 그림을 예로 들면 통신시 신뢰성을 확보하기 위해 IO GateKeeper라는 Monitor를 통해 데이터를 거쳐가게 만들었지만, Source/Destination/메세지의 순서등을 구분하기 위해 Token (Time + Mac Address + Handler 정보) 인 IO Triage 이용하게 되고, IO Triage를 구축하기 위해 내부적으로 Timestamp를 사용하는 모습이 보입니다.
즉 거대한 아키텍쳐적인 결정이든, 그 밑에 세분화된 설계에 대한 결정들이 개별적으로 결정되는 것이 아니라, 서로 간에 영향을 미치며 결정된다는 것입니다.
작년에 Kent Beck님은 세미나에서 이러한 말을 했습니다.
“Design is an island‘ (설계는 섬이다.)
패턴을 몰랐다면 이러한 말이 별로 도발적으로 들리지 않았겠지만, 패턴계에서 늘 원칙처럼 언급하던 패턴이 가져오는 Side Effect를 중화시키기 위해 다른 해결책으로 또 다른 패턴들이 도입되는 그림을 늘 봐온 저로서는 도발적인 정의였습니다.
지난 Rebecca Wirfs-Brock의 Nature of Order I를 이어 그 다음 이야기를 진행하고자 합니다. 혹시 이전 내용을 못 읽으신 분은 링크를 따라 한번 읽어보시길 권해드립니다.
워낙 방대한 내용이라, 섣불리 글이 써지지 않더군요. 철학과 생명체, 사물 (Thing)의 구성 원칙들을 기술하는 것이다 보니, 농업 / 생명 / 건축등 다양한 것을 예로 들어 설명하고 있습니다. 게다가 너무 철학적이어서, 개발자가 읽기에는 지루할수도 있죠. 아직 책을 다 읽지 못했지만, PLoP에서 정리한 노트내용과 NOO를 SW 설계에 빚대어 설명한 논문들 그리고 저의 부족한 경험을 합쳐서 용기를 내어 써 봅니다.
항상 경청하는 자세로 여러분의 피드백을 받겠습니다. 부족한 부분은 말씀해주시고, 더 좋은 의견을 주시면 관련 자료를 더 찾고 공부해서 NOO 데이터를 계속 업데이트할 욕심은 있습니다.
Architecture 101 