설계 능력 측정과 성장을 향한 단서. Methodoloy

설계, 객체지향 능력은 간단하고 구체적인 문제로 알아볼 수 있다.
'인증 후 회원정보 수정'내용이다. 이렇게 단순하지만 구체적인 내용으로 능력을 가늠할 수 있다.

본인이나 팀 기술리더의 위치를 성숙도로 가늠할 수 있다면
이를 바탕으로 성장에 대한 단서를 발견하고 발전해 나갈 수 있다.

특히, 팀내 기술리더나 큰 목소리를 가진 사람들은 측정이 필요하다.
이 사람들은 회사와 팀의 성장을 책임지는 사람이기 때문에 이들의 목소리와 시야가
직급이 낮거나 연차가 낮은 사람들의 성장을 억제하고, 나아가 팀과 회사의 성장을 방해할 수도 있다.

  Talk is cheap. Show me the code  
  어플리케이션 아키텍처와 설계에 퍼져야 하는 문화가 아닌가 싶다. 
  납득할 수 있는 설계를 상대에게 제안할 수 없으면서 
  읽고 들은 그럴듯한 것을 두리뭉실 제안하는 건 꼰대의 값싼 선생질일 뿐이다.

  설계 리뷰는 설명책임(accountability)을 수반하고 구체적이어야 한다.
  가령 할인 도메인에 대한 설계에서 할인이 상품에 묶어있다면 
  빌링할인(쿠폰, 결재수단), 계약할인(기간, 금액, 수량), 통합 할인율과 같은건
  상품에선 판단할 수 없는 책임이므로 할인 위치가 부적절하다는 피드백이 가능하다.
  이렇게 구체적 근거로 피드백이 되어야 하고 그 피드백이 옳은지 그자리에서 검증해야 한다.

  설계리뷰는 결과물의 판단근거가 구체적으로 부합되는지 판단하는 자리다.
  따라서 "결합, 응집, 도메인, 컨텍스트, 객체지향 원칙을 자~~~아알 고려해서.."
  이같이 당연한 원칙들을 언급하는 피드백은 의미도 없고 아무런 도움도 안되므로 피하도록 하자.

성숙단계는 개념적으로 복잡한 것을 요구하는 방향으로 풀어봤다.
성장을 향한 단서에 도움이 되었으면 하는 바램이다. 


[성숙 단계]
1. 학생 신입, 무엇이 중요한지 모른다.
- 전역접 접근의 편의성을 큰 가치로 인식한다.
- 회원 정보를 처리하고 싶다면? 회원 DAO, 회원모델을 직접 사용한다
  가령 납부 연체 회원은 재무 배치프로그램에서 회원 DAO를 호출해서 회원 신용정보를 수정.
  이처럼 회원정보를 다뤄야 한다면 직접 회원DAO를 호출하는데 거리낌이 없다.
- 가능한 사고는 필요하면 구현한다. 보이면 호출한다, DI로 주입한다. 이 정도.

2. 객체지향 공부 시작, 기계적 원칙 적용.
- 기계적으로 인터페이스로 구현을 감추고 상속을 시도하고 4원칙 같은 것들을 적용한다.
- 기계적으로 그럴듯한 것을 반복하기에 옳고그름을 판단할 수 없는 정도다.
- 재사용을 내가 만든 구성요소의 교체, 다른 프로젝트에서의 재사용이란 식으로 받아들인다.
- 그래서 재사용이란 없고 불가능하다는 믿음을 갖는다.

3. 아키텍처 공부 시작, 선언적 설계와 격리의 의미 습득
- 구현에 의존하는 것의 문제점을 인식하기 시작
- 인터페이스 하부에서 발생하는 구현간의 결합(쿼리조인, 구현의존)의 문제점 인식.
- 아키텍처상 격리를 통해 구현간 의존성을 제한하는 의미가 선언적 설계의 한 방편이란 걸 인식.
- CBD(컴포넌트)나 비즈니스 컴포넌트 팩토리, SOA, MSA의 격리를 이해.
- 현실세계를 격리된 요소로 표현할 수 있으며 재사용 할 수 있다는 의미를 이해.
  구성요소가 여러 협력객체에 책임을 제공하는 것을 재사용으로 인식할 수 있다.
- 격리의 배경을 이해하지만 현실세계에서 실현시키는 방법엔 확신이 없다.

4. 객체지향 가능, 결합과 응집 인식 시작.
- 몇가지(변화, 처리시 필수여부) 기준으로 설계를 판단할 수 있고
  결합도를 낮추고 비즈니스 응집력을 높이는 것을 실현할 수 있다.
- 가령, 회원과 인증은 별개라는 인식을 갖는다
  인증 수단이 추가되거나 구현이 변경되었을 때 
  회원은 영향 받을 일은 없어야 하고 그 반대도 마찬가지다.
  [회원정보수정]은 [인증]을 사용하는 관계가 옳다는 판단을 내릴 수 있다.
- 무엇이 중요한지는 인식 가능하지만 가능하게 만드는 수단을 적게 갖고 있다.

5. 개념적 구조화 가능, 구조화, 단일화 인식 시작.
- 개념의 경계를 구분해서 개념, 의존에 대한 단순화가 필요하다는 사고가 가능하다.
- 도메인주도 설계로 얘기한다면 aggregate 사고가 가능한 정도.
- 예를들면, 회원 기본정보와 보안정보는 접근 대상, 정책, 기술이 다르다.
  나름의 기준으로 구조화 할 수 있고 이들에 대한 접근을 일관된 방향으로 규정할 수 있다.
  회원을 아래와 같은 형식으로 구조화 하고 [회원 기본]만 root로 노출할 수도 있다.
  [회원 기본] --> [보안] 개인 보안관련 참고하라. 정보, 정책, 처리, 기술들.
                 --> [신용] 
                 --> [기타]
  (현실에선 개인,사업자,단체,가족, 관계 같은 개념들이 개입되어 이런저런 방식으로 구조화 된다.

6. 대규모 구조화 가능, 도메인에 대한 통찰 가능.
- 개념적 요소들을 여러 기준으로 다양한 형태로 구조화 할 수 있다. ex) 모듈, 컨텍스트, 모델
- 가령, 8명~10명 이상이 필요한 방대한 도메인을 분리하고 구조화 할 수 있다.
  ex) 상품이란 도메인은 사전에 정의된 규칙이고 계약은 발생시점의 확정내용이다.
      계약이란 도메인은 수량, 사용자, 영업내용~결과가 합해진 구매결정내용이다.
      따라서 [계약]은 [상품]을 바라보는 관계가 옳다는 것을 인식할 줄 안다.
      또, [계약]은 계약되기 까지 영업을 통한 조정이 중요하고
      계약후엔 유지, 납부, 업셀링과 같은 것이 중요하므로 정보는 같아도 관심사가 다르다.
      따라서 계약되기 까지의 과정을 가입설계 또는 가계약으로 분리할 줄도 안다.
- 업종에 따라 구조화 형태가 다르다는 것을 인지하고 개념들을 구조화 할 수 있다.
  ex) 정해진 상품에 따라 대금을 즉시 청구하는 도메인도 있지만
      사용료 조정이 빈번하게 발생하고 문제가 되는 도메인도 있다.
      전자는 [재무]나 [입출금]으로 족하다면 후자는 [과금]이란 개념이 필요해진다. ex) 통신쪽

7. 통합 가능, 프로세스화 가능.
- 지식과 경험을 체계적으로 정리할 수 있다.
- 설계를 아는 것, 장점을 아는 것과 일을 해 나가는 것은 다르다.
  뭘 어떻게 할 지 모르면 모델이고 설계고 불가능하다.
  ex) 유비쿼터스 언어는 어떻게 만들어야 할까?
      => 마이크로 서비스를 각 개발자가 개발도중 용어가 다르게 쓰이는 것을  발견하면 
          그것을 중재자가 개입해서 개념을 도형과 선으로 표현하고 다중성을 표시한다.(반나절)
      => 어떤 분의 설계 피드백 글 내용을 옮겨왔다. DDD를 좋아하는 CIO시라고..
- 익숙치 않은 도메인의 레거시 시스템을 비도메인 전문가가
  MDD로 일정기간 내에 구축한다치면 무엇을 어떻게 해야 하는지 설명할 수 있고
  기준을 정의하고 하나하나 일감으로 떨굴 수 있고 
  각각의 설계에 대해서 의미있는 피드백을 명확히 줄 수 있어야 한다.
- 이론적, 현실적인 것을 알아간다. 다만, 효율화를 모색하는 단계라 경험이 필요하다.

8. 성숙
- 경험, 통찰, 발전엔 끝이 없다.

- 내 기준에서 대략적으로 분류한 것이다.
  혹여라도 이 글을 본 사람은 자신의 위치가 
  생각보다 낮다고 우울하거나 기분나빠하지 않았으면 좋겠다.
  나도 4~5년차 까진 1~3번에서 일했다고 생각한다.
  좋은 내용을 읽어봐야 일하는 환경에선 실감이 안되니 습득될 리가..

어느정도의 수준을 가져야 한다는 식으로 오해하지 않았으면 좋겠다.
  대규모 모델링을 요구하는 환경이 아니면 6~7번 설계를 요구하는 일은 적다. 
  가령, 과거 10여년간에 개념적 경계와 컨텍스트로 모델링을 하던 곳은 제 2금융권 정도다.
  대규모 설계와 도약을 요구하는 곳은 한국에선 드물고 그렇기에 경험자체가 쉽지않다.

- 규모가 작은 곳에서 개념적 구조화가 필요없다는 것은 아니다.
  아주 작은 e-commerce에도 매우 큰 도움을 준다. 
  다만 필요성을 느끼거나 올바른 경험을 하기 쉽지 않다는 얘기다.
  MSA가 떠올라 모델에 관심을 갖는 것이지 여전히 논리적 모델이나 설계에 대한 관심은 적다.
  (MSA유행 전에 컴포넌트, 서비스 모델을 채용한 기업이 매우 적었던 것을 상기해보자.
  (MSA도입을 말하면서도 모델주도설계에 대해선 비관적인 경우도 있다.

- 개개인의 경험엔 한계가 있고 처해있는 환경이 다르기 때문에
  학생과 신입, 자그마한 서비스를 전문적으로 운영하는 사람이
  복잡한 도메인에서 필요로 하는 것을 경험하거나 획득할 수 없는 것은 당연하다.
  단지 환경과 경험의 차이일 뿐이니 주어진 환경에서 최선이라 생각하는 것을 하면 된다.
  상대적으로 부족하다고 우울할 필요도 없고 낫다고 비판하거나 비아냥거릴 필요도 없다.
  늘 강조하지만 IT인은 경험을 공유하는 동료다. 서로 구분지을 필요가 없다.

기술적 기법이 우선되는 지점이 있고 개념적인 기법이 필요한 지점이 있다.
  둘은 다른 관점이라 한가지만으로 도약을 일궈낼 수 있다는 주장은 조심해서 받아들여야 한다.
  단순한 문제는 TDD로 충분하다. 단일 데이터처리에 개념적 구조가 필요할 일은 없다.
  그러나 개념적인 복잡성이 관여되면 기술적 리팩토링만으론 불충분하다. 
  (밥마틴, 에릭에반스 둘의 말이다.

- 결국, 환경에 달린 문제다. 
  바텀업은 필수고 탑다운과 개념적인 부분은 환경에 따라 비중이 달라진다.
  기한이 중요하고 복잡한 대규모에선 개념적인 설계와 도약이 상당히 중요해질 수도 있다.
  가령, 비용문제. 하루 지연에 2억 지체 보상금. 같은 환경에선 
  경험적으로 습득한 개념적인 설계 통찰, 도약을 출발점으로 삼는 것이 
  바텀업으로 하나하나 만들어 가는 것 보다 비용 효과성, 위험관리 면에서 유리하다.
  어쨌든 환경 문제다. 한가지 가치만 고집하지 말고 최선이 무엇인지 궁리하자.

테스터를 QA라 부르는 현상. Methodoloy

테스터와 QA는 다르다. 아래 이미지를 참고하자.
용어의 오용, 기인하는 문제에 대해서 생각해 볼 부분이 있다.

1. 팀 업무, 정체성 혼동
용어를 틀리게 사용하는건 정의를 잘못 이해한다는 증거.
팀 명칭을 틀린 용어로 사용하는건 팀 업무, 정체성에 대한 인식 부족.


2. "품질은 결과 확인"이란 잘못된 인식 강화
다른 말로 '과정은 품질과 별개'란 인식이 강화된다.
우린 과정만 통제할 수 있다. 품질 향상은 과정의 향상을 통해 획득된다.
따라서 대개 QA는 결과 확인 보다 목표, 과정(프로세스)에 많은 리소스를 할애한다.
조직이 과정을 품질관리 대상으로 인식하지 못하면 품질을 좌우하는 근본적인 부분을 놓치게 된다.


3. 테스트 이전 활동에 대한 품질인식 저하
"품질 = 테스트"란 인식이 강화된 조직에선 테스트 이전 활동에 대한 품질 인식이 낮다.

소프트웨어 엔지니어링에 상식적인 것들이 있다
- 구축 완료 후 테스트는 제품 품질에 영향을 주는 일부 요소, seguetech
- 결함 제거 비용, 설계(x1), 구현(x6.5), 테스트(x15), 운영(x100), ibm sci
- 첫 테스트 케이스를 실행하기 전에 리뷰를 통해 오류의 90%까지 제거 가능, IEEE 2001
- 오류의 대부분은 요구사항 및 설계단계의 오류로 전체 결함 비용의 64%, journal of dse

품질향상 비용 효과성은 테스트 이전 활동들이 매우 높다는건 상식이다.
그래서 QA는 테스트 이전의 프로세스 품질과 프로덕트 품질 개선 활동들을 활발히 진행한다.
하지만 이름만 QA인 테스트팀을 가진 조직에선 이러한 활동들에 대해서 관심은 커녕 인식 조차 없다.
(왜? 품질이란 결과확인 이란 의식이 굳게 자리잡기 때문이다.


4. 정체되는 조직
cmmi에서ppqa(프로세스와 제품 품질보증), ma(측정과 분석)란
프로세스들은 레벨 2(managed - 관리가 존재하는 조직)에서 등장한다.
즉, 관리되고 향상되는 조직은 제품, 과정, 과정을 좌우하는 요소들을
점검, 측정, 분석, 개선하는 태스크를 명시(롤, 직무, 프로세스로 정의)하고 수행한다는 의미다.
조직에 이러한 부분이 없다면 cmmi 레벨1, 개인역량이 전부인 조직이라 할 수 있다.

QA란 이름의 테스트팀을 가진 조직에선 
팀 롤이 그렇게 정의되었기에 프로세스 품질,프로덕트 품질 영역이 비게 된다. 
그렇게 관리와 향상의 근간이 되는 ppqa, ma 영역이 방치된다. (롤, 권한, 직무 자체가 없다)

그래서 이러한조직은 대개 조직의 자산이 빈약하고, 프로세스와 기법이 낙후되어 있다.
후진적 기법, 프로세스에 허덕이며 무엇이 문제인지 모르는 사태를 겪기 쉽다.
문제는 조직이 대격변을 겪지 않는 이상 조직의 아이덴터티는 유지되고, 후진성 또한 지속된다는 점이다.

측정하고 향상해야 할 부분은 언제까지고 개인 성향과 능력에 좌우되고
조직의 지식과 자산으로 누적되고 향상되어야 할 부분은 계속 공란으로 남는다. 그렇게 조직은 정체된다.
(과정에 대한 노하우와 역량이 뛰어난 개인이 있어도
(조직과 테스트팀의 직무, 성과와 관련 없으므로 조직에 쌓이지 않고 소실되기 쉽다.


5. 쓸모없는 QA팀
개발자나 관리자의 리소스 낭비를 막기 위한 지원이 주 업무인 QA팀들이 있다.
결과 확인, 리포트가 주 업무로 테스트 작성, 관리, 진행, 확인, 보고, 사업관리 지원을 한다.

정체성이 리소스 낭비를 막기 위한 팀인 경우
개발 전문성, 관리 전문성이 없으면서 현상/결과를 보고하다 보니
개발팀과 관리팀 입장에서 반갑지 않은 팀, 무능의 아이콘으로 취급되기 쉽다.
(일을 진행함에 있어서 도움을 주진 않으니 크게 필요로 하지도 않고 달가워 하지도 않는다.

그래서 QA란 이름의 테스터, 지원인력들은 무능하다는 평가를 듣고
시간이 지나도 전문성이 생기지도 않고 커리어가 나아지지 않는다.
그렇게 이름만 QA인팀은 스스로의 정체성, 미래, 업무에 대해 고민하곤 한다. 
(연 수백억, 수천억 이상 매출을 올리는 대기업들의 QA팀도 그러한 경우를 자주 본다


결론, 테스트팀은 테스트팀이라고 호칭하면 된다.
QA라 칭하는 테스트팀도 그러한 팀을 가진 회사도 
몇 분 시간을 내서 위키에서 QA항목을 읽어봤으면 좋겠다.


## 잡다 ##

- 테스트가 중요치 않다는게 아니다. 테스트는 테스트고 QA는 QA다.

QA 채용공고에 필요역량으로 테스트 케이스 작성, 테스트 수행, ISQTB.. 
   이런 것들이 적혀있다. 테스터 뽑는거 맞다.

- 프로젝트에서 QA가 하는 일을 적어보면 테스트와 다름을 알 수 있다.
  QA는 프로젝트 계획을 돕고 개발/관리 프로세스와 기법을 정의, 가이드, 교육, 개선한다.
  (진척, 소통, 관리 대상, 이슈, 위험, 형상을 규정하고 관리하는 방법을 정의한다.
  (수행사의 개발/관리 프로세스를 수용하는 유형별 개발 프로세스
  (요구, 분석, 설계, 이행 기법, 절차, 산출물, 샘플, 가이드, 체크리스트를 제공하고 교육한다.
  (분석하거나 설계할 때 도움이 필요한 인력, 팀에 직접 도움을 준다.
  활동과 결과를 측정, 분석, 모니터링, 통제하고 결과가 기대와 일치하는지 확인한다.
  관련, 문제 발생시 대안을 제시한다. 위험/이슈 완화 계획 수립에 참가한다.
  (맨먼스 미신에서 언급되는 상황 - "지체되는 프로젝트에 개발인력을 더하는건 의미가 없다"
  (이런 상황에서 무얼 어떻게 해야 하는지 해법을 제공하는 것이 QA다.
  (개발/관리 프로세스 정의 책임이 있기 때문에 그러한 활동을 한다.



도메인 모델은 유용할까? Methodoloy

도메인 모델은 두가지 관점에서 유용하다.
1. 설계를 이끌어 가는 도구.
2. 정보와 지식을 집약시켜 문제영역을 학습/소통/향상 시키기 위한 도구.

첫째, 설계를 이끌어 가는 도구로 무엇이 유용할까?
비즈니스 프로세스(유스케이스, 동적관점)  ㄱ
도메인 모델(정적 관점)                     - + 책임할당(GRASP) - 정제 - 설계 모델 + 구현
위 접근은 과거 객체지향 기법들이 취하는 익숙한 방식이다.
유엠엘 컴포넌트, 유니파이드 프로세스, 도메인주도설계 모두 큰 틀에서 동일하다.

thing, 엔터티로 부터 개념 클래스 후보를 마련하고
각각의 유스케이스와 시스템간 상호작용을 도출한 뒤 개념 클래스에 할당하고
클래스간 협력관계를 보고 전체 구조에 일관성을 더하기 위해 병합/분리 하는 식으로 설계해 나간다.

과거엔 도메인 모델이란 용어는 개념의 정적관계를 나타내는 용어였고
데이터 모델, 설계, 용어집의 근간이며, 개념 설계와 책임 할당의 근간으로 유용했다.
현재 도메인 모델이란 용어는 정적관계 표현 ~ 설계모델 까지를 모두 포함하는 용어로 두루 쓰인다.


둘째, 문제영역을 학습, 소통하기 위한 도구로 유용할까?

초기 도메인 모델은 문제영역의 개념들을 소개한다.
정제된 도메인 모델은 문제영역을 소프트웨어로 해결하기 위한 
개념간의 관계, 개념묶음들간의 관계, 정책을 기술한다. 정적인 관점을 대변한다.
그렇다면 동적인 정보는 도메인 모델 어디에 담길까? 당연한 얘기지만 담기지 않는다.
(단순 도메인 모델이건 행위를 표현한 풍부한 도메인 모델이건 정적인 관점이다.
(간단히 예를들어 보자. 입금 흐름이 도메인 모델에 표현될까?

도메인 모델의 존재 이유에 해당하는
비즈니스 행위들은 정적인 도메인 모델과 분리되어 있다.
물론, 개념들간 연관관계로 행위의 면면을 이해할 수는 있지만 전체를 이해하기엔 부족하다.
비즈니스 모델링의 워크플로우를 보자.
비즈니스 모델링(조직, 워커, 프로세스 정의)과 도메인 모델링 트랙이 분리되어 있다.

비즈니스 프로세스를 SW로 떨어트리는 관점으로 살펴보면 이해가 쉽다.
도메인 모델은 어셈블리 라인들의 관계로 이해하면 된다.
어셈블리 라인과 그 관계를 살펴봐서는 
내부에 개념이 왜 있는지 어떻게 협력되는지 이해할 수 없다
어셈블리 라인이 복잡하고 밀접하게 얽혀있으면 더더욱 이해가 어렵다.
시스템 인터페이스를 분리해낸 비즈니스 타입 모델의 관점에서도도 마찬가지다.
(uml component 149 page)

즉, 정보와 지식을 집약시켜 
문제영역을 학습, 소통, 향상 시키기 위한 도구로 
정적인 관점(구조적 관계, 행위의 의존성)을 갖는 도메인 모델만으론 부족하다다.
동적인 정보나 그에 준하는 단서가 있어야 해석할 수 있다.
동의하기 어렵다면 analysis patterns, ddd, appliying uml and patterns 책을 펴보길 권한다
책에 등장하는 도메인 모델을 봤을때 업무가 머리에 그려질까? 
도메인 모델을 보고 업무에 대해서 설명할 수 있을까? 쉽지않을 것이다.

DDD에서는 설계를 주도하는 모델과는 별개로 설명을 위한 모델의 필요성을 언급한다.
설계를 위한 모델은 이를 해석하기 위해서는 맥락이 수반되어야 한다.
맥락이란 위 이미지 처럼 프로세스 흐름, 프로세스의 이유, 목적, 관련 리소스 이유 같은 것들이다. 
과거에 곧잘 사용되던 분석단계의 프로세스 엔터티 매트릭스도 설명목적으로 활용할 수도 있다.

결론, SE관점에서 도메인 모델은 유용하다.
설계를 이끌어 가는 도구로 유용하며,
개념을 집약하고 구조화하며 차츰 향상시켜 나갈 수 있다.
허나, 도메인 모델의 배경, 맥락을 이해하기 위해선 설명을 위한 모델이 적절히 수반되어야 한다.
도메인 모델은 이후 책임 할당, 구조화, 정제를 거치며 코드로 나아간다.


- 기타 잡다 -

1. 모 서적에선 말-도메인 모델-코드로 민첩하게 가자고 말한다. 

현실에서 그런 방식으로 진행하면 어떻게 될까? 사례를 들어보자. 
차세대 프로젝트에서 재무업무를 개발했던 적이 있다.
고객사 보안정책상 업무 범위를 벗어나는 정보는 의도적으로 차단된다.
그래서 개발자의 손에 쥐어진건 도메인 모델과 말(BA-업무를 설명하는 직원) 뿐이다.

애자일스럽고 가벼운 최고의 환경일까? 전혀,. 
개발이 진행되어도, 개발을 완료해도 업무에 대한 지식이 깊어지지 않았다.왜?

도메인에 대한 근본적인 이해는 도메인 모델에 담기지 않는다.
BA가 말로 전달하는건 why와 what이 빠진 how에 대한 편린이다.
단편적인 말로 도메인의 배경과 의사결정이 반영된 how가 적절한 지를 판단할 수 없다.

설계의 적정성은 상호작용, 관계에 의해서 판단된다.
설계의 이유가 되는 상호작용을 일으키는 업무흐름, 요구사항, 배경에 대한
이해없이 내가 정의한 클래스만 바라봐서는 무엇이 올바른 설계인지 판단할 수 없다.

가령, 재무 컨텍스트는 계약 컨텍스트, 계약의 전체 프로세스에 대한 깊은 이해가 수반되어야 한다.
(당시엔 도메인을 이해하기 힘든 이유가 뭘까 꽤나 스트레스 받았었고
(DDD책을 아마존에서 주문해서 뒤적뒤적 읽곤했다.14년 전 이야기다.

원천적인 맥락에 대한 배경지식은 편린과 휘발되는 '말'이 아닌 다른 형태로 제공되어야 한다.
BA의 단편적이고도 휘발되는 말이 뭔가 민첩해 보이지만 실제론 전혀 민첩하지 않다.
국외 애자일 컨퍼런스나 포럼에서 product manager를 없애자는 성토가 이어지는 이유다.
(지식, 이해가 포함된 합의된 결정이 아닌 product manager에 의존하는 것은 좋지 않은 형태다.


2. 현실에서는 도메인 모델을 차근차근 작성하는 경우는 적다
설계와 구현을 "모델"에서 출발한다는 관점을 취하는 경우가 적거니와
구현에 최대한 가까운 지점부터 출발하여 도메인 모델을 생략하는게 보통이다. 아래처럼 말이다.
요구사항 - 구현
요구사항 - 테스트 정의 - 설계+구현
요구사항 - 후보아키텍처가 적용된 분석모델 + 설계(초기 설계) - 구현 + 테스트
어느정도의 규모가 되는 프로젝트에서는 
DA가 여러 업무로부터 주제영역별 개념 데이터를 획득하고
레거시 모델을 참고해서 개념 모델을 정제하고 업무 분석설계자와 검증하는 식으로 진행한다.


3. 모델의 필요성을 부정하거나 과대평가하는 것만 조심하자
- 대형 SI프로젝트에서는 MDD를 많이 채용하지만 
  작은 시스템,앱 구축 프로젝트에선 구현이 우선이다.
  도메인이 작고 직관적이며 프로세스도 간단하고 정보처리성인 경우가 많기 때문이다.
- 현실에서는 간단한 도메인들이 많다.
  따라서 MDD(Model-Driven Design)의 필요성을 크게 체감치 못한다.
  그렇다고 해서 그것이 잘못되었다거나 후진적인 것을 의미하진 않는다.
- 도메인이 단순하면 설계와 업무설명을 요약한 작은 sheet로도 충분하다. 괜찮다.

4. 이해를 돕는 책들
  business modeling with uml - 비즈니스 view의 존재 이유, 모델링 하는 방법
                                  - 비즈니스 view를 sw 아키텍처 까지 이어가는 방법.
  applying uml with patterns -도메인 모델의 목적과 전후에 무엇을, 왜, 어떻게 하는지 설명.
  uml component - 개념을 조직하고 책임을 할당하는 방식에 대한 이해 획득.
  analysis patterns - 도메인 모델 레퍼런스
  lean architecture - 구조에 컨텍스트를 분산시킨 것의 문제점에 대한 이해
  domain driven design - ddd관점에서의 도메인 모델.

5. 혼란스러운 용어
같은 의미를 갖는 것도 있고 다른 의미를 갖는 것도 있다.
   비즈니스 컨셉 모델, 비즈니스 타입 모델, 비즈니스 오브젝트 모델, 
   도메인 모델(일반적인 용어), 도메인 모델(DDD), 개념 데이터 모델..
- 참고로, DDD의 도메인 모델이란 용어는 기존의 도메인 모델이란 용어와 완전히 다르다.
- 최근엔 도메인 모델을 ORM의 모델 용어나 
   Hexagonal architecture 레이어 의미로 사용하기도 한다. 
- 도메인 이라는 말을 남발했지만 현실에선 도메인이란 용어는 줄이는게 낫다.

1 2 3 4 5 6 7 8 9 10 다음