아는 만큼

도메인 주도 설계 번역을 드디어 끝내고 책이  나왔습니다.
공부하려고 시작했다가 어찌어찌 출판사와 연결되었고,
무식해서 용감한 제가 번역을 해버렸네요.
아무튼 덕분에 제 주위 여러 분들까지 덩달아 고생 하셨답니다. ^^;;
이자리를 빌어 다시한번 감사를....

 

책이 나오고, 스터디 하는 분들이 생기면서, "아꿈사"라는 스터디 모임에 초대 받아 개념 소개를 드리게 됐습니다.
아키텍트의 꿈을 찾는 모임이신것 같습니다. 지난번엔 Mongo DB 하셨다 들었고, 이번엔 DDD 인데, (물론 얇은 제 quickly는 아니고, 이대엽님이 번역한 DDD로 하십니다.) 주말에 나와 이렇게 꾸준히 공부를 하신다니 아~~~ ^^

그 자리에서 설명드렸던 자료를 pdf로 올립니다.
DDD 개념 이해에 도움이 되셨으면 합니다.

앞의 글에서 시스템의 경계를 구체화 하는 작업이 분석이라는 저 나름의 정의를 내렸습니다. 그럼 이번에는 이러한 분석 즉 구체화 작업을 성공적으로 진행하기 위해서는 어떤 접근이 좋은지 생각해 보도록 하죠.

경계를 명확히 하는 작업의 성공여부는 두가지로 확인해 볼 수 있습니다. 모든 영역의 경계를 다 표현했느냐와 각 구역의 경계가 충분히 정밀하냐 하는 점입니다. 예를 들어 한 국가 영토의 경계인 국경을 정한다고 할때, 전방위적으로 접하는 모든 다른 국가와의 경계를 정했느냐와, 각 경계가 실제 그 현장에 가, 특정 지점에 깃발을 꽂을 수 있을 정도로 정밀하게 정해졌는가 하는 의미와 같습니다.

그럼, 먼저, 모든 구역, 즉 전방위적으로 빠뜨리지 않고 경계를 정의하기 위해선 어떻게 접근해야 할까요?

시스템이 다루어야 하는 모든 영역을 나열하여 해당 영역별 경계를 정의할 수 있습니다. 이때 영역을 빠짐없이 나열하도록 도구를 사용해 작업해야 하는데, 대표적인 것이 기능 분해도 입니다.  만들어야 하는 시스템을 0레벨로 두고 계층적으로 이를 분할해 가며 작성한 트리구조의 목록이죠. 기능 분해도는 시스템 뿐 아니라 수작업까지 포함하여 업무(or 비즈니스) 기능 분해라는 제목으로도 작성할 수 있습니다.

이 작업에 적용하는 원칙인 MECE는 문제해결 기법으로도 널리 알려져 있습니다. ME, Mutually Exclusive는 분해한 각 영역간 겹치는 부분이 없어야 한다는 의미이고, CE, Colletively Exhaustive는 분해된 모든 영역을 합쳐 놓으면 대상 시스템의 전체가 빠진 부분이 없이 커버되어야 한다는 의미 입니다.

기능 분해도를 잘 작성하기 위해서 업무 흐름도를 사용하기도 합니다. 대상 비즈니스가 어떻게 흘러가는지를 다이어그램으로 표현하면서, 시스템이 수행할 작업과 사람이 수행할 작업을 구분해 나가면, 빠뜨리는 부분이 없이 영역을 파악해 낼 수 있으니까요.

다음으로, 충분히 정밀하게 작성하기 위해서는 무엇을 해야 할까요?

요구사항을 구체화 하는것의 종결자는 단연 화면 정의 입니다. 오랫동안 요구사항을 글로써 구체화 하려는 노력이 있어왔지만, 결국은 화면이라는 최종 결과물을 가지고 고객과 확인하는것이 가장 효과적이고 확실하다는 쪽으로 수렴되고 있습니다.

화면 정의서에서는 크게 두가지 내용을 담게 됩니다. 화면에 단순히 보이거나 사용자가 입력해야 하는 단위 속성 정보들, 그리고 해당 화면을 사용하고 또 다른 화면으로 연결되는 흐름입니다. 이 두가지가 정의되고 고객과 합의 된다면 요구사항은 확정되었다고 할 수 있습니다.



분석을 성공적으로 수행하기 위해 영역을 빠뜨리지 않도록 나열하며, 정밀하게 하기위해 화면을 정의하는 작업을 해야 한다고 말씀드렸습니다.

그렇다면 이런 작업을 어떤 순서로 진행하는 것이 좋을 까요? 영역을 100% 상세히 나열하고 확정한 후 영역1번부터 시작하여 순차적으로 화면을 정의할까요? 이렇게 하는 것이 흡사 폭포수 형태의 접근일 것이고, 일부 영역만 정의한 후 화면을 구체화 하고, 다음 영역을 정의한 후 다시 화면을 구체화 해나간다면 반복적 (iterative) 형태의 접근이 될 것입니다.

많은 프로젝트에서 요구사항의 확정이라는 것이 현실적으로 불가능에 가까운 일이고보니, 저는 반복적 형태의 접근이 불가피할 뿐아니라 효율적인 방법이라고 생각합니다. 그리고, 프로젝트의 기간이 한정된 상황에서 중요 업무에 대해 먼저 구체화하고 차차 덜 중요한 것으로 접근해 나가는 것이 고객과 개발자 모두에게 위험을 최소화 하는 길이기도 합니다. 

기업 시스템-흔히 MIS(Management Information System)이라고 말하는-을 개발하기 위한 분석과 설계 분야에서 10년이 넘도록 일하고 있습니다. 저는 이 영역이 실제 프로젝트 현장에서 전혀 발전하지 않고, 오히려 퇴보하는 모습을 보면서 괴로워 하고 있고, 책이나 해외의 석학들은 여전히 원칙과 기본을 말하는 것을 들으며 벽을 느낍니다.
그래서, 복잡한 것 말고 단순한 것, 하면 좋은 것 말고 꼭 해야하는 것을 제 경험과 지식을 기반으로 정리해보려고 합니다.
읽는 분들에게 조금이라도 도움이 된다면 보람있는 일이겠지요. 이 글이 첫 시작이 되겠네요. 얼마나 자주가 될지 모르겠지만 열심히 정리해 보겠습니다.


오늘은 분석과 설계에 대한 제 나름의 정의를 말씀드리려고 합니다.

일반적으로, 분석이란 시스템 사용자의 업무를 파악하여 만들어야 하는 시스템이 무엇(What)인지를 정의하는 것이고, 설계란 그 시스템을 어떻게(How) 만들 것인지를 파악하는 것이라고 말합니다. 분석은 순수하게 비즈니스에 관련된 것이고, 설계란 기술(technology)에 관련된 것이 되겠지요.

이러한 정의를 기반으로 우리는 시스템을 분석, 설계하고 분석 시에 너무 구현 방식이나 구현 시의 제약사항을 고려하지 말도록 가이드 합니다. 그리고 그러한 기준으로 분석과 설계의 산출물도 구분하고요.

그러나 실제 프로젝트를  수행할 때, 이런 구분은 충분히 자세하지 않거나 혼란스럽다고 느껴집니다. 왜냐하면 분석단계의 대표적인 작업인 요구사항 정의만 해도 얼마나 자세하게 쓰느냐, 어떤 단어를 사용하느냐에 따라 분석, 설계의 경계를 넘나들 수 있으니까요.

그래서, 많이 고민하고 제가 내린 결론은 이렇습니다.
분석은 사용자의 요구사항과 관련된 모든 작업이고, 설계는 이의 구현과 관련된 모든 작업입니다.
분석은 시스템의 경계를 정의하는 작업이고, 설계는 시스템의 내부를 모듈화 하는 작업이구요.


좀 더 구체적으로 설명해 드리겠습니다.

분석 작업의 시작은 시스템의 경계를 대략적으로 스케치하는데서 출발합니다. 예를들면 시스템 배경도를 그리는 것처럼 말이죠. 가운데 개발 대상인 시스템을 두고 주변에 이를 사용하는 사람이나 관련 시스템을 두고 중요한 입출력 데이터를 표시합니다. 이렇게 함으로써 시스템의 대략의 경계를 파악할 수 있게 됩니다.