2주에 한번씩 스터디가 진행되고 있는 SLiPP.net 2기의 스터디가 잠시 무료해지는 틈을 줄이고자, eclipse4j라는 이름으로 활동하시는 현기형이 이터니티님의 강의를 제안하셨다. 다음은 손권남님!

이날은 생각보다 사람들의 참석이 저조했다. 덕분에 회사에서 참석하고 싶어하던 개발자 3명을 이끌고 참석할 수 있었다. 혹시나 스터디를 함께하는 사람들이 불편해할까봐 꽤 조심스러웠다.

시작시간 전에 일찍오신 조용호님(Eternity's Chit-Chat : http://aeternum.egloos.com 운영)은 꽤 쑥쓰러워하셨다. 처음 뵙는 날이라서 나 역시 앞자리에 앉아서 쑥쓰럽게 말을 건넸다. ^^; 제대로 인사를 드리지 못한 점은 많이 아쉽다. 발표가 끝나자마자 바람같이 사라지시더라능!!

• 발표 주제 : Rich Domain Model

위의 주제를 가지고 진행하셨다. 본인께서도 꽤 오래전에 작성한 문서라고 하시면서 쑥쓰러워하신다. 평소에도 쑥쓰러움이 많으실 것 같은 느낌!

발표내용 정리

목차

1. 영화 예매 시스템 도메인
2. 데이터-지향 설계
3. 책임-주도 설계
4. 아키텍처 & 프레임워크
5. 결론

영화 예매 시스템 도메인

• 도메인 컨셉
• 영화
• 할인정책 + 할인규칙
• 상영(예매)
• 할인정책
• 일정액 할인
• 일정비율 할인
• 한개만 적용
• 할인규칙Rule
• 특정 조건
• 한개 혹은 해당하는 조건 적용
• 할인적용 예제
• 영화(8000원) - 일정금액 할인(800원) - (조조, 10회, 월요일 오전, 목요일 오후 상영)
• 조건을 가운데 두면 더 이해하기 쉽겠다.
• 예매

데이터-지향 설계DDD(Data Driven Design)

• 흔하게 사용하는 방법
• 포커스
• 데이터 : 무엇을 저장할 것인가
• DB Schema 와 크게 관련된다
• 클래스에 매핑되는 객체를 선언, Anemic Domain Model
• 프로세스 : 어떻게 처리할 것인가?
• 예매 처리 서비스
• 데이터를 사용한 예매 프로세스 구현
• Dao를 이용해서 데이터를 가져온다.
• 가져온 데이터를 가지고서 로직적용
• 데이터를 저장
• 중앙집중식 제어 스타일
• Transaction Script
• 데이터를 불러오기 비즈니스 로직을 처리하고 저장하는 과정까지가 하나의 트랜잭션에서 처리하기 때문이다.
• 데이터와 프로세스를 나누기 때문에 절차지향적이다.

책임-주도 설계(패러다임 쉬프트!!)

• 객체지향적으로 짠다.
• 객체지향에 초점은 책임, 데이터나 프로세스는 아니다.
• 책임
• 스스로 뭔가를 할 수 있다.
• 이름이 뭐에요~?
• 이름이 궁금한 사람의 지갑을 털어서 신분증을 보고 확인하는 방법
• 궁금한 사람에게 다가가 물어보는 방법
• 이름을 묻는 것에 대해 요청하면 거기에 대답할 책임
• 캡슐화의 원리
• 내가 그 사람의 모든 것을 꺼내어 보고
• 어떻게 하는지는 몰라도 어떻게든 답을 얻는다.
• 다형성
• 자바의 객체는 ’책임의 관점’에서 보지 않으면 이해하기 어렵다.
• 도메인 책임
• 시스템이 해야하는 일
• 예매 생성 책임
• 가격 계산 책임
• CRC 카드 : Canidate, Responsibility, Circulation
• 클래스, 네임, 책임, 협력
• 실제적인 구현은 뒤로 미룬다.
• Rich Domain Model
• 상속inheritance과 다형성의 활용
• 정책에 대한 판단을 하는 책임, 규칙에 대한 판단을 하는 책임이 서로 다르다.
• 데이터에 대한 걱정은 잠시 꺼두라!
• 책임 기반 구현
• 시퀀스 다이어그램으로 확인
• 위임식delegated, 분산식dispersed 제어 스타일
• 이런걸 Domain Model
• 객체지향적인 설꼐를 시도
• 모든 코드의 오류사항은 수정을 가하면서 나타난다.
• 도메인적인 설계만으로는 잘 안된다.
• 변경에 대한 예측을 잘 해야한다.
• 개발자의 능력이 가장 큰 변화를 가져오는구나.
• 요구! 분석! 능력!
• 객체지향적인 코드는 어렵다.
• 유연성을 요구하기 때문에…
• 객체의 생성된 이유를 따라서 들어가야 이해할 수 있다.
• 구조를 이해하고나면 편안해진다.
• 패턴을 이해하고 나면 쉽다.
• 수정시 찾아들어가기 쉬워진다.
• 유지보수는 쉽다.
• 요구사항 변경을 수용하기 쉬운 녀석을 만들어야한다.
• 객체지향 프로그래밍에서 패턴이 유행하게 된 것은 이해하기 어렵기 때문이다!

아키텍처 & 프레임워크

• 계층적 아키텍처
• 도메인 계층이 두터워진다.
• 도메인 레이어 캡슐화
• 도메인에 대한 개념적인 부분들 포진
• 기술적인 부분은 밖으로 뽑아내야 한다.
• 관심사의 분리
• 도메인 계층 위에 서비스 계층을 두는 것에 대한 논의가 있다.
• 서비스 레이어
• 도메인 레이어 의존성 관리
• 순수한 객체POJO
• 자바 언어책을 펼쳤을 때 나오는 자바코드
• AOP, Annotation, DI
• 객체의 관심도를 떨어뜨려주는 거지
• AOP에 대해서 공부할 수 있으면 좋겠다. ^^
• 비침투적인 프레임워크
• POJO 개발을 위한 전제조건
• 가벼운 프레임워크, 도메인에 대한 침투를 피한다.
• Spring, Hibernate
• Dependency Injection - Spring
• Impedance Mismatch
• 객체 모델과 DB 스키마의 불일치
• 객체 모델과 DB 스키마 간의 변환 계층 필요
• DB구조와 객체 구조가 닮아가는 이유
• 이렇게 해야 그나마 편하니까!
• Data Mapper
• 테이블과 객체 사이의 의존성을 끊어준다.
• ORM - Hibernate
• 객체와 DB 구조의 일치…
• Spring AOP & Annotation, 관심사의 분리

결론

• Rich Domain Model
• 설계 관점이지 기술 관점이 아님
• 훌륭한 객체 지향 설계 지침을 따를 것
• 기술적인 제약 사항 역시 중요
• 비침투적인 프레임워크 사용
• 프레임워크의 제약 사항을 파악하라
• 프레임워크의 제약 사항에 따라 구현 가능하도록 아키텍처를 수정하라.
• 도구에 아키텍처를 맞추어야 한다
• Rich Domain Model을 자제해야 하는 경우
• 비즈니스 로직이 단순하고 개발 기간이 짧은 경우
• 비침투적인 프레임워크를 사용할 수 없는 경우
• 비침투적인 프레임워크에 대한 경험이 부족한 경우
• ORM을 사용할 수 없는 경우
• 객체지향 분석/설계 경험이 부족한 경우
• 실용적인 관점에서 접근하라!

기타

• Patterns of enterprise Application Architecture
• ODB(Object DB)
• RDB를 포기하지 않음
• Rich Domain Model 설계를 할 수 있는 절차적인 접근방법이 있을까?
• 도메인에 대한 많은 이해
• 아키텍처에 대한 고려
• Case by Case

도메인Domain을 제대로 이용하기 위해서는 객체지향과 디자인 패턴에 대한 충분한 이해가 있어야 한다. 이런 충분한 이해와 경험이 없다면 도메인을 제대로 구현하지 못할 가능성이 높다.

이전 회사에서 만들었던 솔루션에서 처음으로 DDD(Domain Driven-Design)의 맛을 보았다. 개인정보보호법이라는 도메인을 가지고서 개인정보 프로세스와 법규에 대한 복잡한 로직을 구현하기 위한 선택이었다. 위에서 말했던 비침투적인 프레임워크로 Spring, Hibernate, Spring Data JPA를 활용했으며, 도메인에 비즈니스로직을 담아 사용하게 되면서 서비스 계층이 굉장히 얇아지는 것을 경험할 수 있었다. 도메인간의 연계, 협력이 필요한 경우에만 서비스를 사용하고 그렇지 않은 경우에는 대부분 컨트롤러 계층에서 도메인을 불러와 도메인을 통해 비즈니스 로직을 처리하고 그것을 저장하는 형태로 구현이 되었다. 이 때문에 컨트롤러 계층의 코드가 복잡해지는 단점을 경험하기도 했다.

하지만, 기획자와 도메인에 대한 공유를 바탕으로 도메인에 대한 비즈니스 로직 설계와 기능들을 구현할 수 있었던 것은 좋은 경험이었다고 생각한다.

존재하지 않던 개념들을 도메인으로 추상화 하고 이 도메인을 가지고서 기획자와 협의하고 도메인을 변경하는 작업은 비교적 용이했다. 그러나 도메인에 대한 충분한 이해가 있지 않고 도메인의 크기가 거대해지면 개발자가 그 도메인을 컨트롤하기가 쉽지 않다. 이런 경우에는 도메인을 분리시켜야 하는데, 그걸 개발자가 혼자 진행하기는 버거운 작업일 것이다.

  한달에 한번씩 정보화진흥원에서 열리는 '전자정부 표준프레임워크 오픈커뮤니티 세미나'가 있었다.

  사실 오늘 세미나는 신청자가 워낙에 많아서 뒤늦게 접수하려고 사이트에 갔다가 실패를 했다. 세미나 발표자에 따라서 세미나의 참가신청이 폭주하면서 커뮤니티 사이트 접속이 어려운 상황들이 발생했다. 이에 대응하기 위해서 서버를 확장하고 있다고 한다.

  오늘은 '전자정부 표준프레임워크 Learning Path 2.0'이란 주제로 '양수열'님이 발표를 하셨다. 발표하시는 분이 '양수열'님이어서 그런지 매우 많은 사람들이 참석했다. 200개의 샌드위치를 준비했는데 동이나서, 김밥을 추가주문했을 정도였으니 대략 200명은 넘어섰다고 추측할 수 있었다. 분명 과거에 비해서 스프링3.0이 적용된 표준프레임워크가 제법 쓸만해졌다는 이야기가 돌면서 많은 사람들이 관심을 가지고 있는 것은 분명했다. 그러나 아직은 프리랜서들의 마음을 움직이기에는 부족한 점이 많다. 무엇보다는 사업비용이 과거 정권에 비해서 대폭 삭감되었다는 것이랄까? 풍문으로는 전산화에 책정되어있던 예산이  4대강 사업으로 넘어가면서 SI프로젝트가 팍팍해졌다는 소문도 횡횡했다. IT쪽의 사람들은 지금 배가 고프다. 과거의 빛났던 기억들을 추억거리로 삼아 다시 그날이 돌아오길 기다리고 있는지도 모른다. 그런 기대를 안고서 이 자리에 왔는지 모른다.

  전자정부 프레임워크를 기본 아키텍쳐로 삼아 정부에서 진행하는 SI프로젝트에 참가할 수 있을거라는 기대를 하고 이 자리에 온다. 난 그렇게 추측한다. 세미나의 내용도 대체적으로 그런 경향이 있다. 전자정부 표준프레임워크를 적용하여 공통 아키텍쳐와 컴포턴트가 적용된 프로젝트를 진행하면서 성공적으로 마쳤다는 이야기를 해주고 있다. 주제가 조금씩 다르기는 했지만, 표준프레임워크 세미나에서 진행되는 이야기는 대체적으로 그러했다. 그래서 일까? 5번 정도 이 세미나를 들었지만 이 세미나에서 얻을 수 있는 것은 이제 없겠구나 싶은 판단을 했다. 당장에 공공기관 SI프로젝트에 참여할 계획이 없는 상황에서는 이 세미나가 더이상 매력적이지 않았다. 

사람들이 빽빽히 들어찼다. 이 곳에 참석하는 사람들은 무슨 생각을 하고 있을까?

'바퀴를 새로 만들지 마라.'  필요에 따라서 바퀴는 다르게 만들어야 하지 않을까? ^^; ㅎㅎ

  프레임워크와 라이브러리에 대한 차이는 애플리케이션에 대한 관점에서 판단하는 것이 중요하다. 프레임워크는 애플리케이션에 대한 모든 권한을 관리한다. 생성, 실행과 소멸을 관리하게 된다. 반면 라이브러리는 애플리케이션이 실행되면서 필요에 따라서 참조하는 정도랄까?

  최근에서야 두 개념의 차이를 어렴풋하게나마 이해를 하게 되었달까? 내 뒤에 앉아있던 개발자들은 이런 이야기에 별로 관심이 없었다. 그들 나름의 바람이 있어 이 자리에 참석했겠지만 그것을 만족시키지 못하는 발표였는지 연신 투덜거리면서 자리를 지키고 있었다. 

  '발표'는 발표자와 그 발표를 들으러 오는 '청자' 사이에서 주고자 하는 바와 원하는 바가 일치할 때 그 가치를 발하게 마련이다. 그런데 이번 세미나 발표는 아쉬운 부분이 많이 있었다. 그것은 아마 '전자정부 표준프레임워크'에 대한 내 기대와 사람들의 기대가 높아졌기 때문이 아닐까 생각한다. 이번 '양수열'님의 발표는 'JCO'나 '자바 관련 컨퍼런스' 등에서 적당했다고 생각된다. 발표의 진행도 200명이 넘는 사람들이 모인 상황에서 진행하기에 적합하지 않았다는 생각을 한다. 처음에 말씀하셨던 것처럼 우리나라 개발자들은 그렇게 많은 말을 하지 않는다(많은 사람들이 모여있는 곳에서는 그렇다. 친한 개발자들끼리 모였을 때는 다르지만). 거기에 참석한 사람들은 들으러 온거였다. ^^; 발표자의 질문에 답을 하려고 갔던 것은 아니었다. 그 부분에서 이 발표는 많이 틀어지기 시작한 것이다. 분명 그런 느낌이 들었다. 

  그곳에 오래 있지 못하고 나온 이유 중 하나는 '담배' 연기였다. 이 세미나에 오면 늘상 있는 일이지만, 오늘은 유달리 많은 사람들이 참석한 탓에 강연장 내부 공기도 좋지 않은데, 시작전에 사람들이 피워댄 담배연기가 강연장을 메우고 빠져나가질 않아 목이 건조해지며 헛기침이 일고 답답함을 일으켰다. 더 이상 자리를 지키고 있을 의욕이 없어서 1부가 끝나고 일어설 채비를 했다. 

  그래서 1부가 끝나고, 그 곳에 참가하신 지인을 만나 얼굴도장 찍고 나왔다. 나오는 길에 세미나를 듣고 계신 광남님도 뵙고 인사를 드리고 나왔다. 

  주변의 많은 개발자들이 전자정부 표준프레임워크가 쓸만해졌다는 이야기를 한다. 이렇게 쓸만해진 프레임워크를 이용해서 파이를 키우려고 준비하는 노력들이 보인다. 다음 정권에는 다시 IT 전담부처가 살아나고 IT산업이 다시 살아나길 기대하는 사람들이 많다. 세미나에서 보여주듯 간단하게 플러그인을 추가설치하는 것으로 주요한(구현하기 어렵거나 공통적으로 통일해야할 필요성이 있는)  기능들을 손쉽게 구현할 수 있다면 서로에게 좋을 것이다. 개발환경이 자동화될수록 개발자들에게 여가시간이 생기고 새로운 활동들을 할 수 있게 될테니까. 물론, 이런 변화에 적응하지 못하는 개발자는 도태되어 다른 곳으로 떠나게 되는 것도 당연할 것이다.

  밤이 깊었다. 작년과는 또다른 느낌으로 집으로 돌아왔다.

  작년과는 다른 생각과 시선으로 볼 수 있게 되어가는 듯 하다. 아직 가야할 길이 멀다. 쉬엄쉬엄 천천히 내가 가고자하는 길을 가자.

메모 내용 :

제목 : 전자정부 표준프레임워크 Learning Path 2.0

발표자 : 양수열

장소 : 한국정보화진흥원 무교청사

발표내용 

Framework?

프레임워크 Vs. 라이브러리

애플리케이션에 대한 실행권한을 프레임워크에서 처리한다.

- 재사용

= C & P

= Object : 객체지향 프로그래밍을 해왔는가?

= Component : CBD를 통해서 재사용성을 확보하고 성공한 프로젝트가 있었는가?

-> 캡슐화, 커스터마이징의 어려움

-> 프로젝트에서 발생할 수 있는 공통적인 문제를 해결할 수가 없다.

= Framework

-> 프로젝트에서 발생할 수 있는 문제를 해결하기 위한 반제품

- 패턴들이 묻어 있지

- 문제 해결을 위한 기능들을 탑재한 기능을 제공하는 반제품

- 업계의 불편한 진실

= 프레임워크를 왜 쓰는가?

= Servlet과 JSP 만으로 게시판을 잘 만드시는 분?

= Servlet으로 파일 업로드 프로그램 가능한 분?

= Http request 에서 mine type 어떻게 가져올까?

= 객체 누수가 없는 커넥션 풀을 만들 수 있는가?

- 아, 담배냄새...는 싫다.

- 우리는 왜 못할까?

= 바퀴를 다시 발명하지 말라.

- eGov에서 해결하고자 하는 이슈

= 대규모 한국형SI 프로젝트

- eGovframe 소개

= 공통컴포넌트 + 표준프레임워크 -> 정보시스템 A, B 개발

= 개발방식의 변화 : 기능 개발 -> 비즈니스로직 개발에 중점을 두는 것으로 변해간다.

= 개발자가 가지고 다니던 도구들을 하나로 모음

- 그러고보면 나도 양수열님 발표를 처음 듣게 되는군.

- 사람이 많고, 담배연기가 남아있어서 목이 컬컬하고 안좋아. 갈거야.

- 아쉽지만, 이번 발표는 발표자와 수요자들의 조합이 어울리지 않아.

- 발표자는 국내 SI를 비롯한 전반적인 면에 대한 이야기를 나누고 프레임워크의 필요성에 대한 이야기를 나누려 하지만,

- 세미나 참가자들은 자신들이 전자정부 표준프레임워크를 사용해서 공공기관SI프로젝트에 적용가능한가에 대한 확신을 얻고 싶어한다.

- 모든 사람의 요구사항을 충족시켜줄 수 없겠지.