통일장 이론의 한계

Posted at 2010.09.14 11:54 // in Principle // by MOOVA 무바㏇
아인슈타인은 죽기전까지도 통일장이론[각주:1]을 완성하려 했다.

모든 물리학 법칙에 적용되는 이론을 단 하나의 이론으로 설명하기 위함이었다.
과학자들은 어떤 학문을 연구할 때 그것과 관련된 파생된 연결고리를 묶어서, 통합된 하나의 이론으로 설명하려고 하는 이상과 목표가 있다고 한다. 그들이 목표로 삼고 있는 통일장 이론...
그들이 생각하고 있는 것 처럼 전혀 연관성 없는 학문도 하나의 이론만으로 설명되어 진다면 얼마나 간편하고 위대해질까?

일전의 포스트에서 신과 태양의 관계를 설명하면서, 태양을 알기 위해서 태양을 연구하는 것이 얼마나 바보같은 행위인지 설파했다. 태양자체를 연구하는 광적인 광신도의 행위보다 태양이 가져다주는 편의성과 행복감을 느낄 수 있으면, 그 힘의 존재를 그저 인정하게 된다는 말이었다.

적절한 예시였다고 생각한다.

우리가 어떤 목표로 갈 때 우리는 우리의 잣대로 사물을 판단하고 이해하려한다.
만약 어떤 것이 진리인 양 사람들을 현혹하고 있다면 진실을 쫓는 사람은 그 본질을 쫓기 위해 그 자체를 연구하려 들것이다. 하지만 이것은 시간 낭비다. 자신의 시야만 편협해질 뿐이다. 자신의 울타리 내에서만 통일을 시도하려 하는 것이다. 정작 자신은 통일장 이론이라고 주장하겠지만, 이것은 어디까지나 한 울타리내에 통일장 이론에 불과하다. 더 높고 넓은 시야를 볼 의지가 있다면 그 자체의 본질만을 따지지 말고 한차례 뒤로 물러서서 조용히 흘러가는 구름들을 관찰하기 바란다. 그렇게 된다면 나와 내가 속한 공동체가 얼마나 비굴하고 역겨운지 또는 얼마나 우물안 개구리였는지 깨닫게 될 수 있을 것이다.

2010:09:14 11:26:14

통일장이론을 완성하려고 했던 아인슈타인

자신만이 갖고 있고, 설법하려 했던 이론들이나 지식은 이미 누군가가 현실에서 써먹었다고 생각하면 된다. 마치 자신이 어떤 금형서에 못으로 침을 박아 그 이론들이 자신에게만 나올 수 있는 것인양 착각하는 오류는 범하지 말기로 하자. 어느정도 홍보와 설법을 하는 것도 하나의 재주에 속하겠지만, 그것을 정리하게 된 계기나 시도가 마치 전부 자신이 했던 업적인양 착각하는 바보가 되진 말자. 대 부분 그러한 사람이 금형서에 새긴 문구들은 나 같은 피라미 조차도 이미 현실속에서 써먹고 알리려고 했던 지나가는 그저 일상생활과 이론에 불과했다.

멀찌감치 떨어져서 구경한번 해보자. 구경하는 자체가 얼마나 자신에게 넓은 시야를 가져다주는지 곧 이해할 수 있으리라. 만약 그런 시도 자체도 하지 못한다면,

"우린 언제나 도진 개진일 뿐이다."

# 무엇하나 했다고 해서 통일하려 들지말자. 자신이 가지고 있는 편협한 지식을 통일하려 하지 말자. 누군가는 때때로 그 상위에서 놀고 구경하면서 지켜볼 수도 있는 노릇이니까:)
# 온라인의 한계. 종종 누군가는 그 편협한 잣대 속에서 살아가고 판단하고 있다. 사람은 온라인에서  판단할 수 있는 그런 종류가 아니다.

  1. 통일장 이론은 자연계의 4가지 힘인 중력, 전자기력, 약한 상호작용 그리고 강한 상호작용을 통합하려는 시도의 대표적인 접근 방식이다.

중력장과 전기장, 자기장 그리고 핵력장이 같은 근원을 지닌다는 자연 철학이다.
 [본문으로]
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

[공통규격의 표준화] 팀의 성격을 파악하는 일

Posted at 2010.09.07 09:59 // in Principle // by MOOVA 무바㏇
2010:08:19 13:37:35

오크팀은 짧은기간의 일정때문에 부랴부랴 TO를 내어 만들어 놓은 '급한팀'에 속했다. 그들의 이력을 보면 개개인별 기술력은 모두 출중했다. 그러나 뭉쳐놓으면 이른바 오합지졸의 상태가 되곤 했다. 개개인이 맡아서 진행했던 모듈은 제대로 된 상태를 볼 수 없을 만큼 말 그대로 정리 안 된 수준의 코드들이 각 모듈 사이에 의존한 채 당연한 듯 꽈리를 틀고 있었다. 소스코드 관리조차도 진행하는 것이 두려울 만큼 너무 혼잡한 상태였고, 자신이 맡았던 Task도 제대로 끝내지 못한 채 타인의 Task에만 관심을 두는 그런 행태가 벌어지고 있었다. 한번은 그들의 장급에게 물어보았다."왜 프로젝트가 이지경인가?" 하는 말에  "잘 알고 있다. 그러나 어쩔 수 없다." 또는 "이런 프로젝트 처음보냐. 어쩔 수 없다." 라는 변명섞인 말만 늘어놓았을 뿐이었다. 왜 그들은 서로 떼어놓으면 슈퍼맨, 붙여놓으면 오크가 될 수밖에 없었던 것일까? 해당 프로젝트에서 본인은 5시에 칼퇴근을 하더라도 기능구현이나 AA의 일 그리고 프로젝트 내 표준을 잡아주었던 반면,
그들은 10시까지 남이 있어도 이런 현상을 "어쩔 수 없다"라며 한탄만 늘어놓을 뿐 자리만 차지하고 앉아 있을 뿐이었다.
(여기서 오크팀은 가상의 팀이 아닌 실제 프로젝트에서 만나봤던 팀이다.)

문제점의 발견

해당 프로젝트에선 공통팀이 있었으나 여전히 소통없는 활동만 하고 있을 뿐이었다. 각 모듈사이의 기능별 난위도 수준은 상위급에 속했지만, 여전히 서로의 팀웍은 맞지 않았고, 공통팀과 업무팀이 여전히 나뉘어 진채 서로간의 의존성만 높아져 갔다. 공통팀이 공통모듈을 하나 고치게 되면 업무팀의 모듈까지 그 영향을 끼치게 되어 다음날이면 모두 소스코드컴파일 에러가 났다. 또 그 다음 날도, 또 그 다음 날도 그런 현상이 아침마다 나타나고 있었으며, 누구 하나 이 상황을 고치려 하지도 않고 관심조차도 없었다.

2010:09:05 19:51:47

Figure 1. Framework increament level

개인적으로 진단해 보건데 소프트웨어 진화단계에서 해당 TA와 공통팀은 범용 프레임워크의 첫 단계조차 진입하지 못한 상태였다. 업무모듈은 여전히 공통모듈에 의존하고 있었고 기술적인 모든 부분을 공통에 맡긴 채 책임 회피할 구멍만 찾고 있었다.

2010:09:05 19:59:32

Figure 2. 비즈니스 모듈이 공통모듈에 의존한 채 결합도만 증가하고 있는 모습

OOAD(Object Oriented Analysis Design)의 활용


한가지 아이디어만 잘 쓰면 이와 같은 병목현상을 줄일 수 있는데, 모두 뒷 짐만 진채 책임회피만 할 뿐이었다. 경험상의 차이인걸까? 아마도 숲을보는 노력보다는 나무만 바라보기에 급급했던 것일까?  "프로젝트 단계가 꽤 흘러서 지금 이 상황을 고칠 수도 없다."라는 관리자의 변명뒤엔 윗선에 거짓보고만 할 기색만 역력했다. 또한, 이 팀은 기술의 중요성은 알고 있었지만, 기본적인 디자인 원칙조차도 지키려 하지 않았다는 것을 알 수 있다.

OOAD의 The Stable Abstractions Principle (SAP) 안정 추상 개념 원칙[각주:1]과 , Open Closed Principle (OCP) 원리를 따르면 위와 같은 상황을 아주 간단하게 아래와 같이 바꿀 수 있다.

2010:09:05 20:07:49

Figure 3. 의존성을 낮춘 추상화 모듈

또한, 당연하게도 해당 공통팀은 CCP원리를 따르지 않고 있었던 것이다.
 
- CCP(The Common Closure Principle )는 "공통모듈은 폐쇄되어야 한다"[각주:2]라는 디자인 원칙중 하나이다.

위 아이디어 하나로 매 아침마다 소스코드 에러와 개발자간의 병목현상은 보이지 않았다. 공통팀이 해당 모듈을 수정해도 수십개나 되는 비즈니스 모듈을 수정하지 않아도 됐다.

그러나 아직까지 해당팀 내부에 있었던 수많은 문제점중 한 가지만 고친 상황이다.
난지도위에 쓰레기 하나를 치운다고 난지도가 궁중이 될 수 없다. 해당 프로젝트에선 기술적으로 JFace를 사용하고 있었는데, JFace란 SWT의 프레임웍 격으로 MVC패턴을 따르는 전형적인 뷰기술중 하나이다.

해당 프로젝트에 참가하고 있었던 대학원출신의 인물들은 POJO라는 단어를 생소하게 여기고 있었다. 몇 년간 폐쇄적으로 컨테니너 박스에 지낸것일까? MVC프로젝트에서 필수로 꼽히는 엄격한 규칙도 무시한 채 그냥 뷰에 ADD하는 식으로 데이터를 연결하고 있었다. 말은 어찌나 많고 그렇게 당당한지 해당 모듈을 수정하고 컨설팅해주러 갔던 나에게 오히려 그런 상황에 대해 되려 나에게 화를 내고 있었다. 전형적인 양은냄비같은 스타일이다. 말이나 되는가? 수없이 뿜어져 나오는 그 말 뒤에 숨기고 있던 그가 만든 모듈은 CRUD중에서 C조차도 구현 못 한 찌끄래기만 발견되었을 뿐이다. 장담하건데 그런 사람은 서버를 개발하나 뷰를 개발하나 어딜가도 말뿐만 늘어놓고 일을 회피하는 것이 전부일것이다.

-- 제발 타인에게 피해를 주는 그런 사람이 되지 말자.


공통표준화의 시작

여기서 지향하고자 하는 것은 개선된 범용 프레임워크이다. 이는 교육기관이나 API, 또는 기술을 습득한다고 해서 될 문제가 아니다. 우리가 결국 구축해야 할 소프트웨어는 도메인에 특화된 프레임워크를 건설하는 것이지 교육기관에서 교육해준 것을 그대로 따라 하는 행위는 아니기 때문이다. 마치 개발자가 SQL을 작성할 때 경험이 없으면 한계를 보이는 것처럼 꾸준한 프로젝트 경험만이 개선된 범용 프레임워크를 구축할 수 있지 않을까.

2010:09:05 21:33:27
Figure4. 진화된 프레임워크

MVC프로젝트에서 MVC를 지키지 않는다는 것은 프로젝트의 규칙을 무시하는 것과 같다. 소프트웨어 컨플릭트에서는 표준을 너무 높게 잡거나 또는 낮게 잡아도 문제가 될 수 있다고 한다. 하지만, MVC프레임워크는 범용적인 솔루션이고, 그런 체제에 모델1식의 개발을 한다면 결국 나중에 피치 못할 문제점을 일으킬 것이다. "해당 뷰에 그냥 ADD해라"라는 대충식의 개발자식 마인드가 점점 쌓이고 쌓여 결국 프로젝트를 좀 먹고 있는 것이란 것을 왜 모를까? 본인은 수 차례 프로젝트에서 그런 기본적인 규칙을 무시했을 때 나타나는 피치 못할 문제점들을 직접 겪어보았기 때문에, 다시 한 번 이런 문제점을 수정하기 위해 해당 뷰와 데이터연동에서 또 한 번 추가적인 아키텍쳐를 잡아주었다.

2010:09:05 20:48:58

Figure 5. Jface 뷰활용, 별도의 CustomWrapper를 제작하여 자체 특별한 데이터를 연동한 그림.

MVC체제에서 모델1으로 개발하는 작태가 빈번히 이뤄지고 있었으므로 어느 정도 프로젝트에 규격화된 모듈을 필요로 했다. 공통 모듈이 표준화 되어있을 때 이 체제를 따르는 개발자와, 따르지 않는 개발자를 구별할 수 있는 방법이기도 한데, 범용적인 프레임워크에 + 도메인 특화된 프레임워크를 추가하여 진화된 프레임워크로 발전 시키는 게 첫 번째 목표였으며, 프로젝트 표준을 재정의하는데 두 번째 의의를 뒀다.
보통 JFace Viewer에서 데이터를 연동할 때 사용하는 메소드가 있는데 Viewer.setInput(List);이라는 메소드이다. 프로젝트내에 공통된 뷰, 다시 말해 공통코드를 포함하는 뷰를 제작하기 위해선 미리 정의된 공통코드를 참조해서 API를 제공해야 한다. 그래야만 해당 컴포넌트를 원하는 개발자들이 프로젝트 규격에 맞게 사용할 수 있는 표준성을 제공할 수 있다.
(The Reuse/Release Equivalence Principle (REP) 재이용 개방 등가 원칙).
 setInput(List)이라는 메소드는 다음과 같이 재정의한다.

setInput(new Hendler<Model>(COMMON_CODE_NUMBER))


JFace는 MVC에선 Model을 적절하게 사용해야만 MVC를 한다고 할 수 있다. Model을 제외하고 단순하게 데이터만 조회해서는 공통규칙에 어긋날 뿐만 아니라 차 후 피치 못할 에러를 발생시킬 수 있다고 미리 이야기한 바 있다. 사용하고자 하는 모델타입을 Generic Class로 넘겨주고 사용할 Code Number를 파라미터로 넘겨준다.

2010:09:05 21:16:35

Figure 6. Viewer.setInput에 넘겨줄 Handler 상속구조. Model은 Generic Type으로 지정한다.

위의 공통 표준 건설로 개발자들은 해당 Viewer를 구현할 때 다음의 API를 따라갈 것이다.
(물론 데이터베이스의 컬럼명을 조회해서 뷰와 매핑시킬수도 있다. 그런 방법은 아주 간단한 방법이기 때문에 공통 아키텍쳐가 아닌 공통 라이브러리라함이 맞다.)

TableViewer tableViewer = new TableViewer(parentComposite, SWT.NONE);
Table table = tableViewer.getTable();
table.setHeaderVisible(true);
table.setLinesVisible(true);

tableViewer.setContentProvider(new CustomContentProvider<Member>());

TableViewerColumn viewerNameColumn = new TableViewerColumn(tableViewer, SWT.NONE);
viewerNameColumn.getColumn().setText("Test");
viewerNameColumn.getColumn().setWidth(100);

viewerNameColumn.setLabelProvider(new CellLabelProvider() {
    public void update(ViewerCell cell) {
        cell.setText(((SomeObject) cell.getElement()).getSomeProperty());
    }
});

tableViewer.setInput(new TableHandler<Member>(COMON_CODE_NUMBER));


사전에 미리 Model까지 결정해서 넘겨주므로 공통 폐쇄 원칙을 잘 따른다고 볼 수 있다. 한가지 유념해야 할 것은 공통을 정의할 때 The Stable Dependencies Principle (SDP)안정 의존 원칙을 따르는 것인데, Handler를 Class로 정의하지 않고 interface로 지정해 두면 더 나은 안정성을 확보할 수 있다. interface가 된 Handler는 inner class로 사용될 수도 있다.
여기서 한가지 문제가 될 수 있는 것이 ContentProvider이다. JFace의 ContentProvider는 말 그대로 내용을 정제해서 해당 뷰에 뿌려주는 데이터를 편집하는 클래스이다. Handler에서 모델에 의존성을 추가하였으므로 ContentProvider도 Model type을 넘겨주어야 한다.

private static class ContentProvider<T> implements IStructuredContentProvider {
public Object[] getElements(Object inputElement) {
               T w = (T) inputElement;
                return w.getMemberSet().toArray();
}
public void dispose() {
}
public void inputChanged(Viewer viewer, Object oldInput, Object newInput) {
}
}

 위와 같은 원리는 ContentProvider와 LabelProvider에 대해서는 Figure 7. Figure 8을 참조하길 바란다.


Figure 7. TableViewerColumn과 CellLabelProvider의 DataFlow

Figure 8. ContentProvider와 LabelProvider의 DataFlow

공통규격을 표준화 하는것은 팀의 성격을 파악하는 일이다.


적절하게 공통규격을 정의하는 일은 힘든 일이다. 경험으로 숙성된 개발자만이 공통 아키텍쳐를 적절하게 건설해 줄 수 있다. 위에서 말했듯이 진화된 범용프레임워크로의 도약은 교육기관에서 받은 교육이나 기술만 안다고 될 일이 아니다. 그전에 객체설계원칙과 디자인원칙을 잘 습득하고 있어야 하며, 프로젝트 전체를 파악할 수 있는 눈이 필하기도 하다.

또한, 공통규격은 응용이라는 항목도 포함하고 있어서 팀의 문화와 성격 그리고 역사까지 알면 더욱 좋다. 기간은 3개월인데 위와 같이 공통을 정의한다면 그야말로 쓸데없는 시간낭비가 될 수 있다. 이 같은 경우 상세하게 하는 것보다 빠르게 하는 것이 더욱 효과적이기 때문이다. 반면 프로젝트 기간이 1년이상이고 상세하게 하는 것이 중요한 시점이라면 도메인에 특화된 프레임웍정의나 공통규격을 표준화하는 것은 정말 중요한 행위이다.[각주:3]

매번 새로운 것이 나온다고 그것을 습득하려고 아웅다웅하는 모습이라던지, 새로운 기술을 아는 것이 전부인 양 기술중심 사고방식을 벗어나지 못하면 우리는 너무도 중요한 설계원칙과 큰 물을 보는 자질을 빼먹을 수가 있다.  대부분의 개발자들은 나무하나 건설하기 바쁘다고 한다. 굳이 전체적인 규칙이나 공통을 정의해서 표준을 잡고 따라가면 뭐하느냐라는 불평도 한다. 하지만, 위의 사례에서 볼 수 있듯이 전체적인 관점을 보는 사람이 프로젝트내에 없으면 프로젝트는 산으로 가게 되어 있다. 또한, 숙성된 개발자가 전체적인 안목을 키울 자질이 없으면 10년을 하나 20년을 하나 코더의 눈을 벗어날 수 없다. 그런 자질과 인재가 필요한 시점이지 않을까? 더 상위의 개념을 학습하고 꾸준히 실무에 적용해 볼 일이다.

※ 해외오픈소스인 AgileGridGEF의 원 소스를 배껴 자신의 패키지를 구축할 시간이 있으면, 그전에 디자인 설계원칙부터 스터디 해보길 바란다.



위에서 설명한 OOAD 디자인 원칙은. OOAD의 5가지 원리이외에 파생된 원리에 속한다. 잘 알려지지 않은 아키텍쳐 패턴과 같이 OOAD도 잘 알려지지 않은 디자인 원칙들이 존재한다.



참조 도서


소프트웨어개발의지혜(AGILESOFTWAREDEVELOPMENT)
카테고리 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학
지은이 로버트 C.마틴 (야스미디어, 2004년)
상세보기

Object-OrientedAnalysisandDesignwithApplications,3/e
카테고리 과학/기술 > 컴퓨터 > 프로그래밍
지은이 Booch, Grady (Addison-Wesley, 2007년)
상세보기

Domain driven Design: Tackling Complexity in ...


Eric Evans - 2004 - 568 페이지
books.google.co.kr - 도서 정보 - 도서 검색결과 더보기 »

소프트웨어컨플릭트2.0
카테고리 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학
지은이 로버트 L. 글래스 (위키북스, 2007년)
상세보기

참조 URL
http://www.eclipse.org/gef/
http://sourceforge.net/projects/agilegrid/




 
  1. 안정된 패키지는 추상 패키지가 아니면 안된다. [본문으로]
  2. 패키지내의 클래스는, 공통된 변경이유에 대해서모두 닫혀 있지 않으면 안 된다. [본문으로]
  3. 상세하게 하는것이 좋을까? 빠르게 하는것이 좋을까?에 대한 답변입니다. [본문으로]
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

[아키텍쳐] 보유하고 있는 책

Posted at 2010.09.06 08:52 // in Principle // by MOOVA 무바㏇
2010:09:05 22:38:26
2010:09:05 22:39:40

보유하고 있는 아키텍쳐 책이다.
이 중에서, 소프트웨어 아키텍쳐 이론과 실제는 독학 후 교육을 받은 예외 케이스이다.
처음엔 이 영역에 대해서 이해도가 낮아서 고생을 했는데, 그 후 주기적인 관심을 둔 탓인지 아키텍처 영역도 중복되는 부분이 많다는 것을 깨닫는다. 아직 멀고도 험난한 이 길 선상에서 그래도 잠시나마 위안을 주는 그런 종류의 책이다.

소프트웨어아키텍처이론과실제
카테고리 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학
지은이 렌 베스 (에이콘출판, 2007년)
상세보기
제9회 JOLT상 수상작

실무 사례를 통해 익히는 소프트웨어 아키텍처 지침서. 이 책은 소프트웨어 아키텍처의 개념 설명에서부터 저자들의 실무 경험을 통한 소프트웨어 시스템의 설계, 명세, 확인 작업의 핵심 기술들을 소개한다.

또한 실무에서의 아키텍처 사례 연구를 통해 소프트웨어 시스템을 설계하는 방법과 시스템 구성요소들의 상호작용과 역할, 실제 환경에서 구현할 수 있는 법에 이르기까지의 내용을 제시한다.

<소프트웨어 아키텍처>는 아키텍처 개요와 수립, 아키텍처 분석과 확산으로 구성했다.

☞ Jolt 상 - 해마다 가장 뛰어난 소프트웨어 개발 서적을 선정하는 Software Development 잡지의 상




소프트웨어아키텍처2.0성공하는솔루션을위한비즈니스와아키텍처의만
카테고리 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학
지은이 루크 호만 (에이콘출판, 2009년)
상세보기
성공하는 솔루션을 위한 비즈니스와 아키텍쳐의 만남

『소프트웨어 아키텍처 2.0』는 현실에서 성공할 수 있는 아키텍처와 마케팅 정보를 어떻게 통합해야 하는지, 기술과 비즈니스 관점에서 날카롭게 지적하고 상세히 설명한다. 소프트웨어 전문가인 저자는 아키텍처에 관한 결정을 내릴 수 있도록 중요한 방향을 일러준다. 이 책은 실제로 도움이 되는 가이드라인을 제공한다.


데이터아키텍처전문가가이드(2010)
카테고리 컴퓨터/IT > 컴퓨터공학 > 데이타통신
지은이 편집부 (한국데이터베이스진흥원, 2010년)
상세보기

 

데이터아키텍처 전문자격(DAP, Data Architecture Professional) 대비 수험서. 이 책에서는 산업 현장에서 데이터 아키텍처 전문가에게 요구되는 세부 업무와 자격 검정안내 등에 대하여 상세히 설명하고 있다. 효과적인 데이터베이스 구축을 위한 전사 아키텍처를 비롯 데이터 품질 관리, 데이터 요건 분석, 데이터 표준화, 데이터 모델링, 데이터베이스 설계와 이용 등의 실무 가이드로 구성됐다.

전 세계가 놀랄만한 IT 역사를 창조한 IT강국 우리 대한민국은 짧은 시기에 정보시스템 구축과 확산의 시대를 넘어서 이제 정보서비스품질(Information Service Quality)에 대한 관심과 평가가 요구되고 있으며 정보품질을 위한 투자와 노력을 필요로 하고 있다. 정보서비스품질 고도화를 위한 핵심 요소는 바로 정보의 원천이 되는 데이터 분야이며 이를 위한 데이터아키텍처 전문가 육성이 절실한 시점에 본 자격검정의 탄생을 기쁘게 생각하며 본 검정이 데이터 강국 코리아 건설을 위한 서막의 디딤돌이 되어 우수한 데이터 전문가가 배출되기를 간절히 바란다.
조광원│비투엔컨설팅 대표이사

정보화가 어느 정도 이루어진 기업의 경우 매일 엄청난 규모의 데이터가 쌓이고 있고 연간 수십억원의 비용이 지출되고 있지만 정작 데이터의 활용은 만족스럽지 못한 것이 현실이다. 이는 진주를 돼지우리에 버려두고 있는 것과 마찬가지라고 할 수 있다. 좋은 데이터를 확보하여 바른 의사결정으로 연결시키기 위해서는 데이터확보, 축적, 흐름, 활용 등을 체계적으로 관리해야 한다. 본 자격검정은 "데이터에 의한 경영"의 세계로 가는 좋은 나침반이 될 것이다.
김인현│투이컨설팅 대표이사

데이터는 시스템의 골격이다. 데이터가 바로 서지 않고서는 시스템이 결코 온전할 수 없다. 그럼에도 불구하고 데이터의 진정한 전문가는 찾아보기 어려운 것이 작금의 현실이다. 거의 모든 개발요원들이 애플리케이션만 중시하고 데이터는 프로세싱을 위해 잠시 보관해 두는 창고쯤으로 여기고 있다. 이러한 접근방법은 시스템을 복잡하게 하고 유지보수에 너무 많은 자원을 투입하게 만들었다. 늦은 감이 없진 않지만 이제라도 데이터를 바로 세울 수 있는 전문가들을 양성할 수 있는 자격검정이 탄생된 것을 정말 다행으로 생각한다. 자격검정은 이제 진정한 데이터 전문가를 육성하는 횃불이 될 것이라 믿어 의심치 않는다.
이화식│엔코아컨설팅 대표이사



뷰티풀아키텍처19인의아키텍트가들려주는아름다운이야기
카테고리 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학
지은이 디오미디스 스피넬리스 (지앤선, 2010년)
상세보기

소프트웨어 설계에 숨어져있는 아름다움을 살펴보는 아키텍처 이야기!

소프트웨어 설계와 아키텍처를 이끌고 있는 19인의 아키텍트가 들려주는 아름다운 이야기 『뷰티풀 아키텍처』. 소프트웨어 회사에서 아키텍처를 결정하는 아키텍트의 역할은 매우 중요하다. 이 책은 우리 주변에서 건축물을 보듯이 다른 훌륭한 아키텍트가 만든 아키텍처가 어떤 모습인지 살펴 볼 수 있게 하였다. 일류 소프트웨어 디자이너들과 아키텍트들이 선호하는 소프트웨어 아키텍처에 대해 기술하고, 개발 뒤에 숨은 이야기를 총 5가지 테마 영역으로 풀어내고 있다.


 

저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

애플리케이션 아키텍트 - 그의 한계

Posted at 2010.08.19 15:12 // in Principle // by MOOVA 무바㏇
한 프로젝트에서 조직의 포멧과 비즈니스 프로세스를 개정했을 때의 일이다.(Solution Engineer)
해당 프로젝트에서 AA가 작업한 결과물과 문서, 그리고 활동한 이력에 대해서 한번 살펴보았다. 그 문서는 말 그대로 공통된 템플릿 위주의 스타일로 구조를 설계해 놓았다. 보통 설익은 AA가 잘하는 것 중에 하나는 교육기관에서 정리해준 정석 스타일의 시스템 구조를 특수한 프로젝트에서도 그대로 사용하는 행위이다. 범용적인 교육을 이제 막 받은 아키텍트가 그것을 그대로 따라하는 것은 좋은데, 너무 범용적인 교육에만 의존하여 그것이 전부인 것처럼 생각하는 이들이 많아서 본 글을 시작하겠다. 


교육기관의 범용적인 지식을 넘어서.


보통 AA가 하는 롤중에 하나는 시스템 특징에 적합한 설계와 구현의 지침인 아키텍쳐를 작성하고, 이것을 개발팀 전원이 파악할 수 있도록 하는 것이다. AA가 하는 프레임웍 설계와 관련해서 예외관리, 메시지관리, 트랜젠션 관리, 로깅전략, 레거시 시스템과의 연계등은 한때 교육기관에서 한창 신나게 교육을 하고 있었고 아직도 많은 프레임웍 설계자들이 이 규칙을 따라서 프로젝트를 수행하고 있다. 이렇게 교육기관에서 행한 범용적인 지식은 모든 시스템에서 공통되게 사용할 수 있다는 이점이 있고, 규격에 따라 정의해 놓은 스타일로 그 템플릿에 맞게 프로젝트를 운용할 수 있다. 하지만, 이것은 어디까지나 범용적인 일이다. AA는 위와 같이 공통된 애플리케이션 전략을 세우는 것에 덧붙여 프로젝트 특유의 포멧과 가치 사슬을 포함하면서 공통된 구조(Common Spot)[각주:1]를 확장한 핫 스팟(Hot Spot)[각주:2]을 식별할 줄 알아야 한다.


애플리케이션 프레임워크의 영역.


애플리케이션은 크게 애플리케이션 레이어와 프레임워크 레이어로 구분된다.
프레임워크 레이어는 다시 애플리케이션 프레임워크 레이어와 시스템 프레임워크 레이어로 구분된다. 
시스템 프레임워크 레이어는 .net과 java같은 파운데이션 영역의 프레임워크 이고, 애플리케이션 프레임워크는 도메인 프레임워크와 범용 프레임워크 레이어로 다시 분할된다. (그림 1)

2010:08:19 14:19:46
그림 1. 범용 프레임워크와 도메인 프레임워크

바로 여기에서 교육기관에서 가르치는 것은 범용의 영역이란 것을 확인할 수 있다. (교육기관의 이론적 교육은 상당히 범용적인 것이어서 우리는 다시한번 실무에서 활용하고자 하는 응용력을 키워야 한다. 응용력은 교육기관에서 가르쳐주는 것이 아니다.)

범용 프레임워크는 비즈니스 도메인 지식을 포함하지 않는다. 따라서 범용 프레임워크는 비즈니스 도메인에 관계없이 대부분의 애플리케이션에서 공통으로 발견될 수 있는 컴포넌트와 서비스로 구성된다. 범용 프레임워크의 예로는 Struts,Spring Framework, Spring.NET,Seams,WebWork등이 이에 속하고, 동시에 범용적인 오픈소스들로  활용하고 있는 영역이다. 하지만 그것은 어디까지나 범용 프레임워크 레이어에 국한돼서이다.

도메인 프레임워크는 특정한 비즈니스 도메인을 대상으로 하는 프레임워크 컴포넌트로 구성되며, 특정한 비즈니스 도메인의 모든 애플리케이션에 공통된 비즈니스 지식을 구현한다. 프레임워크의 개발은 대상 애플리케이션에서 공통성과 가변성을 분석하는 것에서부터 시작한다. 공통성이 나타나는 위치를 공통 스팟(common spot)이라고 하고 가변적인 위치를 핫스팟(Hot spot)이라고 한다. 핫 스팟은 애플리케이션마다 가변적이어서 프레임워크를 커스터마이징 할 수 있는 위치이다. 이것이 바로 도메인 프레임워크 레이어를 확장할 수 있는 지점이다. 


애플리케이션 아키텍트는 프레임웍만 잡는 사람이 아닌.


그림2는 범용프레임워크가 도메인(특화된) 프레임워크로 점점 발전하는 개발 과정을 나타낸 그림이다.
2010:08:19 13:37:35
그림2, 도메인 프레임워크 레이어로의 발전

설명하자면, 범용 프레임워크로 구축된 시스템1에서 복사해서 붙여 넣기한 시스템2로 진화된다. 시스템2에서 나타난 문제점들을 개선하고 점차 도메인성격에 맞는 프레임워크로 진화된다. 시스템3과 시스템4는 초반에 범용적인 프레임워크에서 시작한 문제점을 제거하고 조직특화된(도메인특화된) 도메인 프레임워크로 점차 진화된다.

따라서 실력 있는 AA가 되고자 하려면 교육기관에서 지정한 행위이상으로 자신에 조직에 맞는 지식을 기반으로 가변성과 공통성을 식별하는 응용력이 아주 중요하다. (실제로 필자와 같은 솔루션 컨설턴트는 AA와 함께 더불어서 이러한 도메인 영역의 특수한 틀을 지속적으로 발전시켜주는 역할을 하기도 했다.)

2010:08:19 14:31:17
그림3. 아키텍트는 범용적인것을 넘어서 도메인(특화된) 영역을 볼 수 있는 자질이 필요하다.

AA는 범용적인 지식과 도메인 지식을 잘 융화시켜야.


조직A,조직B,조직C에서 사용된 프레임워크에서 공통된 레이어를 추출해서 범용적인 패턴으로 만드는 것은 매우 쉬운 일이다.
하지만 공통된 패턴을 넘어서 조직에 맞는 포멧과 가치사슬에 따른 프로세스, 또한 도메인 특화된 프레임워크를 지속적으로 키우는 노력은 오랜 기간이 필요하며 숙성된 경험이 바탕이 되어야 한다.

필자는 초보강사나 설익은 2년 미만된 아키텍트들이 단 한번의 교육을 받고 ( - 로깅전략,트랜젝션전략, 메시지전력등 공통된 전략들에 대해서 왈가 왈부하면서 ) 대형 프로젝트를 수행하는 것을 보고 상당히 의아해하곤 한다. AA가 하는 영역은 그게 전부가 아닌데 그것이 전부인 것처럼 포장하는 행위를 보고 매우 실망한 적도 있었다. 물론 모든 아키텍트들이 도메인에 특화된 영역에 대한 중요성을 모르는 것은 아니지만, 롤만 차지하고 앉아 있는 설익은 AA를 보면 좀 더 노력하라는 말을 전하고 싶다.

우리가 범용적인 교육을 받고 프로젝트를 진행하거나 컨설팅 역할을 단기간에 할 수는 있겠지만 범용적인 교육은 언제까지나 범용적일 수밖에 없다. 우리가 하고자 하는 것은 결국 소프트웨어 공학이며 소프트웨어 공학은 경험과 지속적인 피드백을 통해 발전시켜야만 하는 영역이다. 그리고 그들은 범용적인 것과 함께 또는 그것을 넘어서 수년간 개선된 도메인 프레임워크를 구축할 때 진정한 애플리케이션 아키텍트라고 할 수 있지 않을까 생각해 본다.

참고

1. 공통 라이브러리와 프레임워크는 다른 개념이다. 공통 라이브러리란 애플리케이션에서 공통적으로 사용할 수 있는 함수들의 집합이다. 그러나 프레임워크으 경우에 제어 흐름의 주도권은 프레임워크에 있다. 다시 말해, 프레임워크에서 애플리케이션 코드로 제어 흐름이 이동된다. 이것을 제어의 역흐름(inversion of control)이라고 한다.

2. 시스템 컨설턴트, 솔루션 엔지니어들은 범용적인 교육으로부터 흘러나온 지식을 전달해 주는 사람이 아니다. 수년간 숙성된 연구를 바탕으로 범용 프레임워크 이상의 도메인에 특화된 지식과 경험을 물려주는 행위를 하는 사람이다.

3. 프레임워크를 구지 분류해보고자 한다면, 스프링 프레임워크는 범용적인 프레임워크에 가깝고,(SOA What & How에서), Windchill은 도메인 프레임워크 영역이다. 또한 LafJ나 가우스,AnyFramework,WiseGrid등은 도메인프레임워크에 가깝다. 그리고 Struts나 Strtus2와 같은 경우 범용 프레임워크에서 도메인 프레임워크로 개선시켜줄 공통 패턴들을 많이 준비해 놓고있다. 만약 웹 영역에서 프로젝트 기간이 짧고 단기간에 도메인 프레임워크로 발전하고자 한다면 필자는 오픈소스인 Struts2를 선택할 것이다. 하지만 장기간에 걸쳐 도메인 프레임워크를 발전시키고자 한다면 필자는 여전히 Windchill이나 스프링프레임워크를 선택할 것이다.
 여기서 중요한 것은 이와 같은 기술의 선택은 매우 중요하지만 더욱 더 중요한 것은 지식과 경험을 지속적으로 발전시켜 조직에 맞는 특화된 도메인 프레임워크로 발전시키는 노력이다.



참고 서적 :
SOAWHAT&HOW:AROADTOSOA
카테고리 컴퓨터/IT > 웹사이트 > 웹서비스
지은이 전병선 (와우북스, 2008년)
상세보기
SOA(서비스지향아키텍처)
카테고리 컴퓨터/IT > 웹사이트 > 웹서비스
지은이 토마스 얼 (에이콘출판, 2006년)
상세보기

소프트웨어공학(제8판)
카테고리 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학
지은이 LAN SOMMERVILLE (홍릉과학출판사, 2008년)
상세보기

시스템분석과요구공학
카테고리 컴퓨터/IT > 컴퓨터공학 > 시스템분석/프로그래밍
지은이 류성열 (한티미디어, 2009년)
상세보기

프로젝트관리의해법
카테고리 경제/경영 > 경영전략 > R&D경영/CFO
지은이 J 데이빗슨 프레임 (한언, 2007년)
상세보기

THEARTOFPROJECTMANAGEMENT마음을움직이는프로젝트관리
카테고리 컴퓨터/IT > OA/사무자동화 > 오피스 > 프로젝트관리
지은이 스콧 버쿤 (한빛미디어, 2006년)
상세보기


  1. 공통성(commonality)에서부터 나온 지점 [본문으로]
  2. 가변성(variability)으로부터 나온 지점 혹은 인터페이스 [본문으로]
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

평행우주와 클로저(Closure) - 언어의 날개를 달자

Posted at 2010.08.04 09:07 // in Principle // by MOOVA 무바㏇
JSP를 막 시작하신 분이,  이 글을 읽고 무엇을 이야기하는지 잘 모르겠다고 합니다. 앞으로 기술적인 글을 올릴때는 별을 달아두겠습니다. ( ★ : 초급 ★★ : 중급 ★★★ : 고급이상 ★★★★: 매니아급)


본 글의 속성은 ★★★★ : 매니아급에 속합니다.

2010:08:03 14:14:36


필자는 정적인 언어 이외에 동적인 언어의 단순함과 묘(妙)의 세계에 대해서 오래전 전부터 탐구하고 있다. 실제로 정적인 언어에서 볼 수 없는 동적 타이핑의 매료는 실로 말할것도 없이 강한 매력을 가지고 있다. 프로그래머라면 어느 한 가지 언어에 종속되지 말아야 한다고 생각한다. 가능한한 때에 따라서 환경에 따라서 선택사항이 되는 것도 프로그래밍 언어의 이점이다. 지구상에는 너무도 많은 언어가 만들어지고 있으며 어떤 것은 인기를 끌고, 어떤 것은 죽고 있다. 이런 시점에 우린 필요에 따른 언어의 선택이 필수적이다. 하이라이브러리의 쓰임이 대세인 요즘, 동적인 언어의 세계에 빠져보는것도 자신이 쌓아두고 있던 적막한 세계의 벽을 허물 수 있는 계기가 될 수있다.



2010:08:03 12:39:47

 

클로저와 클로저를 사용해야 하는 이유?

클로저가 나온 개념은 자바가 나온 지 20년 전부터 나온 개념이라고 한다. 클로저는 글로번 변수와 객체들을 포함하는 코드 블록이다. 그 안에 있는 변수들은 코드 블록안에서 정의된 채로 숨어있고, 코드블록을 호출할 때 정의해 놓은 변수와 그것을 정의한 함수를 결합해 새로운 환경제어영역에 결합함으로써 유연한 결과를 도출하게 해준다. ( 클로저는Groovy, JavaScript, Ruby, Python에서 기본으로 제공하는 함수에서 찾아 볼 수 있다. )

클로저안에는 함수 언어(Functional language)라는 개념이 포함된다. 함수는 기본적으로 빌딩 블록으로 되어 있으며, 다른 프로그래밍 방식이 제공하지 못한 새로운 환경을 제공해 준다. Javascript의 Prototype Chain을 연상해보면, javascript에서 활용하고 있는 Functional Programming에 대한 감각을 익힐 수 있다. (그림 1-1은 일반적인 프로그래밍 방식의 구조를 나타내고, 그림 1-2는 함수언어에 대해서 표현했다. 클로저와 함수형 언어의 보다 자세한 학습은 다음의 서적에서 참고할 수 있다. : Full introduction to Closure, a full lisp variant for the JVM 2010 )

그림 1-1. 일반적인 프로그래밍 구조

2010:08:02 04:29:39

그림 1-2. 함수형 언어의 구조

2010:08:02 04:29:50

 그림1-2를 보면 함수안에 함수를 리턴인자로 받아 쓰고 있다. 코드블록안에 다른 코드블록을 참조하고  또 그 코드블록은 다시 다른 블록을 참조함으로써 끝없는 뜬 처럼 연결지을 수 있다. 이것은 참으로 신선한 개념이다. 함수를 코드블록단위로 분할하고 함수들을 적절히 배합함으로써 원하는 결과를 도출해 낼 수 있다. 내부에서 돌아가는 모듈은 그대로 놔두면서, 제어할 수준의 모듈을 코드블록단위로 수정함으로써 원하는 결과를 얻어낸다. 또한, 기존 Java와 C와는 다르게 함수의 인자로써 함수를 건네받을 수 있고, 리턴된 값으로써 함수를 받아 올 수 있다. 이것은 글로벌 변수에 의존하지 않은 블록단위의 이점을 관점의 분리(separation of concerns)를 할 수 있게끔 하는 중요한 포인트이다.

그렇다면 함수형 프로그램을 사용하게 됨으로써 우리에게 가져다주는 이익은 무엇인가? 객체지향 프로그래밍에서는 재사용과 확장성 그리고 모듈화를 강조한다. 그것이 객체지향 언어의 성공적인 열쇠이기 때문이다. 하지만 함수 프로그래밍은 더 나아가서 객체지향보다 더 향상된 모듈화(modularization)를 가능하게 해 준다. 프로그래머에게는 더 빠르고, 더 편하게, 간단하게 집약적인 모듈들을 개발할 수 있는 여건을 제공해주며, 각자의 모듈들은 서로 재결합되고 재창조 된다. 이것이 함수 프로그래밍의 특성이며 클로저의 묘(妙)이다.

번외이야기

클로저와 함수형 프로그램은 물리학의 끈 이론과 평행이론에서 검증되고 있는 우주의 탄생원리와 사뭇 비슷한 느낌을 전해준다. 어느 날 갑자기 빅뱅이라고 하는 물리적 현상에 의해 우주가 탄생되었다. 그리고 이 이론은 이미 우주론에서 정설로 받아들여지고 있다. 이렇게 생성된 우주는 없던 것에서부터 갑자기 출현한 게 아니며, 이미 다른 모태 우주의 파장으로부터 새로운 우주가 생겨났다. 이렇게 생성된 우주는 자식우주라고 불리며 빅뱅이론에 의해서 점점 더 팽창해 나간다. 어미로부터 탄생한 자식우주들은 따로 놀지 않으며 서로 상생을 유지하며 자연의 법칙에 따라서 공존한다. 자식우주들의 상생은 우리가 생활하는 이 현실에 또 다른 현실이 존재한다는 의미로 받아들여지고 있으며, 자식우주의 배합은 또 다른 초 현실을 만들어 내는 배경이 되기도 한다. 자식우주와 자식우주를 연결짓는 것은 블랙홀에 의해서 통신된다고 알려졌다. 블랙홀(클로저)의 Input과 Output은 통로로 연결되어 있으며 이것은 다시 새로운 우주와 소통할 수 있는 모듈을 의미한다.
"이렇게 우주의 평행이론을 함수형 언어와 비교해 볼 때, 우주는 프로그램에 해당하며 자식우주는 함수, 즉 각각의 모듈을 의미하며, 블랙홀은 함수에서 전달받은 인자나 혹은 리턴값을 연상하게 해 준다."


그림 2-1. 평행 우주와 클로저

2010:08:03 10:18:48


 

파이썬의 함수형 언어와 클로저의 묘(妙)

 이제 다시 프로그래밍 이야기로 돌아가서 함수형 언어와 클로저의 묘(妙)를 실제 코드를 통해서 살펴보기로 한다. Python에선 lambda함수라는 익명 함수를 제공하는데 이는 필요할 때 바로 불러 쓸 수 있는 유용한 일회성 함수이다. 이 익명함수는 함수가 호출되고 끝나는 시점에 메모리에서 바로 소멸되고 생성된다. lambda함수는 reduce,map과 같은 함수와 함께 사용되고 있다. 아래 코드의 예제는 reduce와 lambda함수를 사용함으로써 클로저에서 구조와 행동이 어떻게 실행되는지 쉽게 알아볼 수 있는 코드이다..

foo = [2, 18, 9, 22, 17, 24, 8, 12]
print reduce(lambda x, y: x + y, foo)

foo는 배열로 선언된 리스트이다. reduce의 두 번째 인자로 이 리스트를 넘겨 준다. 일회성 함수인 lambda함수는 reduce의 첫 번째 인자이다. 이 결과값은 112인데 동작원리는 그림 3-1에서 보는 바와 같다.  

그림 3-1. reduce함수와 lambda함수의 실행원리

2010:08:02 05:04:27

 lambda함수는 재사용 없이 간단한 함수를 쓰고자 할 때 쓰는 Python의 익명함수이다. 만약 lambda함수만을 변경한 채 상위의 코드에 바꿔치기한다면 결과는 어떻게 될까? lambda함수를 변경하고 위의 실행구조에 그대로 적용해보자.( lambda x , y : x + y 를 lambda x , y : x * y로 변경했다. )  

foo = [2, 18, 9, 22, 17, 24, 8, 12]
print reduce(lambda x, y: x * y, foo)


2010:08:02 05:04:37

그림 3-2 reduce함수에서 lambda함수만을 바꿔치기 한 예제


결과 값은 279189504로 변경되었다. 기존 프로그램 구조는 그대로 둔 채 익명함수만 바꾸어 실행 전략을 변경했다. 행동(Behavior)을 변경하고 상태(State)값은 그대로 놔두면서 보다 빠르고 획기적인 프로그래밍을 할 수 있도록 도와준다. 이 예제가 바로 클로저를 대표하는 예제라고 할 수 있다. reduce함수는 외부에서 글로벌 변수로 정의된 배열을 받아들여 변경될 수 있는 상태값으로 정해놓고, 인자로 받은 익명함수에 의해 제어를 일괄적으로 맡겨버린다. 배열의 숫자만큼 반복해서 원하는 결과를 도출해 내는 것이다. 

2010:08:02 05:24:29

참고1. 클로저에서 함수는 행동과(behavior) 코드블록을
의미하며 배열리스트는 상태값을 의미한다.

자바스크립트의 함수형 언어와 클로저의 묘(妙)

Javascript에서 사용하고 있는 Closure와 Function Programming는 Python보다 더 직관적이고 대중적이므로 그것을 이해하는데 더 수월하다. javascript에서 쓰고 있는 모든 함수는 객체이다. 함수 객체 안에는 외부에서 접근할 수 없는 private변수들을 할당할 수 있고 private변수는 코드블록에 의해서 제어 당한다. 이는 javascript의 함수라도 외부에서 호출 불가능한 변수가 있을 수 있으며, 그것을 제어하는 public함수로 숨어 있는 변수를 콘트롤 할 수 있다는 의미이다. 먼저 javascript의 클로저를 활용한 예제를 보기로 하자.

 var People = function(){
  var password = '1234';
  return {
   getPassword : function(){
    return password;
   },
   setPassword : function(pass){
    return password = pass;    
   }
  } // (0)

 }();

 alert(People);
 alert(People.password );             // (1)
 alert(People.getPassword());      // (2)
 alert(People.setPassword(5678));// (3)

javascript에서는 함수를 정의할 때 function(){...}();의 형태로 프로그래밍하면 함수를 정의하자마자 바로 실행을 할 수 있다.
1. 여기서 return문의 중괄호 블록은{} Peole이 참조하고 있는 코드블록(Closure)이 된다.(0)

2. People안에 password변수는 People의 지역변수이므로 함수 외부에서 호출이 불가능하다(1).
3. 하지만 People이 참조하고 있는 return블락의 메소드를 이용하면 쉽게 password를 제어할 수 있다.(2).(3) 
YUI의 Javascript Arcitect인 Douglas Crockford씨는 클로저와 관련된 여러가지 패턴을 소개하는데 유명함으로 학습하기를 권한다. 위에서 볼 수 있듯이 코드블록은 외부에 제어권을 넘겨주지 않는다. 블록 내부에 숨어서 그것이 호출될 때까지 대기 상태에 있으며, 그것이 호출될 시점엔 자신과 자신을 포함한 영역을 제어한다. private맴버변수를 public method로 제어할 수 있는 java bean의 형식과 닮았다. 이것이 javascript의 클로저이다. 위의 코드를 확장해 클로저를 포함한 함수형 프로그래밍에 대해서도 알아보자.


 var People2 = function(controlFunction){
  var password = '1234';
  var controlFunction = controlFunction;
  return {
   getPassword : function(){
    return password;
   },
   setPassword : function(pass){
    if( controlFunction )
     password = controlFunction( pass );
    else
     return '패스워드 입력시 함수형을 정의해 주세요';
    
   }
  }
 }

 var executeFunction = function(pass){
  return pass * 4;
 }// (1)
 var people2 = new People2(   function(pass){
         return pass * 4;
            }
         ); // (2)
 people2.setPassword(5678);
 alert(people2.getPassword()); // 22472

People2 = function(){..}(); 형식을 제거하고 코드호출시 바로 실행하는 것을 방지했다. 이는 따로 익명함수를 인자로 받을 것을 대비한 프로그램이다.  People2 에서 받고 있는 controlFunction은 password를 암호화할 수 있는 함수이다. 이것은 People2내부에 정의되어 있지 않으며 외부에서 작성한 뒤 People2가 인스턴스 될 때 인자에 넘겨준다(1). 때에 따라선 제어를 할 함수를 익명함수로 넘겨줘야 할 때도 있으며 executeFunction와 같이 재사용할 일이 없을 때 주로 쓰이는 기법니다(2).People2 의 setPassword 를 보면 인자로 받은 익명함수영역을  if( controlFunction )와 같이 호출한다. 패스워드를 입력할 때 암호화할 수 있는 영역을 외부함수로써 제어권을 넘긴 형태이다. 기존의 구조를 그대로 놔두고 executeFunction 를 수정하여 패스워드 암호화를 바꿔보자.

....
var executeFunction = function(pass){
  return pass * 10;
 }
var people2 = new People2(  executeFunction ); // (2)
 people2.setPassword(5678);
 alert(people2.getPassword()); // 12340

executeFunction 함수만 변경했을 뿐이고 People2의 인자에 넘겨주엇다. password의 최종 결과값은 12340이다. javascript에서 클로저와 함수형 프로그래밍을 적절히 응용하면 Prototype.js와 같은 자바스크립트 프레임웍 제작에 유용하게 쓰일 수 있다. 이는 필자가 종종 프로젝트에서 응용하는 방법이며 다른 개발자들에게 공통 프레임웍을 제공해 줄 수 있는 유일한 수단이기도 하다. 외부개발자들은 프레임웍 핵심인 숨겨있는 변수를 제어할 수 없으며 단지 코드블록내에 정의되어 있는 클로저만 호출해서 쓸 뿐이다. 숨길 것은 숨기고 공개할 것은 공개함으로써 프로젝트내 공통 컴포넌트를 제작할 수 있게 도와주며, 고수준의 프로그래밍을 할 수 있게 도와준다.

자바의 함수형 언어와 클로저의 묘(妙)

필자는 java를 좋아하니 스프링 프레임워크에서 쓰고 있는 함수형 프로그래밍의 활용을 잠시 보기로 하자.


public void saveOrUpdate(final Employee employee){
 HibernateCallback callback = new HibernateCallback(){
  public Object doInHibernate(Session session)throws HibernateException,SQLException{
   session.saveOrupdate(employee);
   return null;
  }
 }
 hibernateTemplate.execute(callback);
}

HibernateCallback을 생성해 HibernatTemplate의 execute메소드의 인자로 넘긴다. HibernateCallback은 callback function의 대표적인 예이며 위와 같이 익명클래스로 HibernateCallback 인터페이스를 생성할 때 doInHibernate를 미리 정의해 둔다. 이런 형태가 Java에서 쓰고 있는 대표적인 클로저의 형태이다. (주로 익명 클래스로 쓰이고 있다. 다만 현재까지는..) .

public interface Predicate<T>{
 boolean accept(T value);
}

public static <T> Collection<T> filter(Predicate<T> pred, Collection<T> coll){
 Collection<T> out = new ArrayList<T>();
 for (T item:coll)
 {
  if(pred(accept(item))
   out.add(item);
 }
 return out;
}

return CollectionUtils.filter(new Predicate<String>(){
 public boolean accept(String value){
  return !value.startsWith(".");
 }
}, names);


Java의 CollectionUtllls에는 Python의 filter함수와 같이 Collection의 Row를 필터링해주는 기능이 있다. 세 번째의 CollectionUtils.filter영역을 보면 새롭게 재정의한 accept메소드안에 문자열 값이 "."으로 시작하지 않는 String값을 필터링한다. 이는 Predicate를 사용자 컨트롤 영역에서 제어하는 방법으로 쓰일 수 있으므로 기존 코드블록의 손상을 줄여준다. 하지만 아직까지 Java의 함수형 프로그래밍은 한계가 있다. 완벽한 Closure를 지원하지 못하고 있다는 것이 그 원인이다. 만약 위와 같은 프로그래밍 방법을 아래와 같이 수정가능하다면 어떤 이득을 얻을 수 있을까?

mappingFilter = CollectionUtils.filter(predicate,
                         { Sgtring x => !"." });

코드가 심플해졌다. 단순해지고 명료해졌다. 사실 앞으로 릴리즈하게 될 Java7에서는 위와 같은 클로저와 함수형 프로그래밍 방법이 제안되고 있으며 Closure의 도입이 확정되었다.

잘쓰면 이익, 못쓰면 독인 클로저

Ruby와 Python,Javascript와 같은 동적인 언어는 이름영역을 따로 관리할 수 있는 메모리가 존재한다. 이것은 C와 Java와는 다른 개념이다. 이 이유때문에 동적인 언어는 컴파일 시점이 아닌 실행시점에 객체의 맴버변수를 추가할 수 있으며 삭제할 수 있다. 확장면에서는 실용적이고 기존의 코드베이스를 손상하지 않는 방법이라 생각한다. 하지만, java와 같이 정적인 언어에서 이와 같은 동적인 프로그래밍 방법을 도입한다면 어떤 이득과 손실이 생길지 아직도 의견이 분분하다. 특히 기술관련 매니아급들이 왕래하는 포럼에서는 자바에 함수형언어를 도입해야 할지 말지를 끝없이 논쟁중에 있다.

잘 쓰면 이익이고 못쓰면 독이니, 앞으로 java7의 운명이 궁금하지 아니할 수 없다. 다음 편은 Java에서 제안되고 있는 Closure와 함수형 언어에 대해서 알아보도록 하자.

저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기
  1. 2010.08.05 14:18 [수정/삭제] [답글]

    비밀댓글입니다

  2. Favicon of http://minimonk.net BlogIcon 구차니

    2010.08.05 14:20 신고 [수정/삭제] [답글]

    파이썬을 공부 하다가 람다가 머하는건가 모호했는데 그넘이 클로저 관련이군요
    음.. 그런데 C에서도 함수 포인터로 넘기면 되는데 이런저런 제약이 있긴 하지만
    일단은 기초 사고 방식이 C의 절차적 방법론에 가까워서 ㅠ.ㅠ 아직은 잘 이해가 안되네요.

    아무튼 저때문에 써주신 글같은데 이해름 못해서 죄송해요 ㅠ.ㅠ

    • Favicon of http://moova.tistory.com BlogIcon MOOVA 무바㏇

      2010.08.08 13:02 신고 [수정/삭제]

      갑자기 생각나서 올린 글이었어요. 이런 글은 생각날 때 올려야 제대로 된 글이 나오더라구요^^
      정적인 언어든, 동적인 언어든 상황에 맞게 선택해서 내것으로 만드는게 제일 중요한것 같아요. 또, 밑바탕이 되는 노력도 필요하겠구요.

      단, 어느 특정 기술이 최고다라는 홍보성 사탕발림엔 넘어가지 맙시다. 기술은 언제나 흥망성쇄가 있기 마련이니까요~

댓글을 남겨주세요.

Spring Security - OID, SID, ACL 2

Posted at 2010.07.23 09:39 // in Principle // by MOOVA 무바㏇

Spring Security의 Domain ACL[각주:1]에선 개별의 Entity객체에 CRUD권한을 걸어둘 수 있다. Role,URL,Resource등 여러가지 자원에 자물쇠를 걸어두는 것은 일반적인 권한 상식이나 실행중인 클래스에 권한을 걸어두는 것은 지극히 드문일일 것이다.
(Windchill의 ACL 편집기에선 Domain Class기준으로 ACL을 설정할 수 있다. JPA도 그렇고, 기타 시큐리티 오픈 소스도 그렇고 좋은 사상은 언제나 배껴가고 복사하고 따라가게 되어있다. 모방은 창조의 어머니라고 하지 않았나)


그렇다면 구지 왜? 실행중인 클래스에 자물쇠를 걸어놓고 사용자에 따라서 차등을 두어야 하는 것일까? Role과 URL권한, 메소드 권한까지 모자라서 클래스에 왜? 이와같은 번거로운 작업을 해야하는 것일까?

한가지 시나리오를 상상해 보자.

2010:07:23 08:41:59
Figure 3. 성인과 청소년에 대한 도메인 클래스의 인가처리


ROLE_ADMIN과 ROLE_USER는 성인과 청소년으로 구별되어 있다. index.task 자원과 Document.word자원 또한 모두 통과 가능할 것이다. 하지만, 도메인클래스영역을 보자. 성인은 Adult 클래스를 조작 가능 하지만, 청소년은 Adult 클래스를 조작하지 못하도록 해야한다.
만약에 청소년이 Adult클래스를 조작가능하다면 이 시스템에 접속하는 대부분의 유저들이 나이를 불문하고 성인물을 감상할 수 있을테니까 말이다. 결과적으로 Domain Class에 권한에 따른 설정을 해 두면 별도의 프로그래밍없이 다음과 같은 뷰를 볼 수 있을 것이다.


성인
---------------------------------------------------------------------------------------------------
제목                               분류                        등급                          대여자
---------------------------------------------------------------------------------------------------
구르물섯달버서난..           액션                        일반                         오승택
라스트사무라이                액션                   성인(19)                         오승택
---------------------------------------------------------------------------------------------------


청소년
---------------------------------------------------------------------------------------------------
제목                               분류                        등급                          대여자
---------------------------------------------------------------------------------------------------
구르물섯달버서난..           액션                        일반                         오승택
---------------------------------------------------------------------------------------------------


이처럼 Domain Class에 자물쇠를 걸어두면 세부적인 사항까지 구현할 수 있게 도와줄 뿐만 아니라, 객체분할과 같은 논리적인 영역까지 그 범위를 넓히게 한다. 또한 클래스당 권한을 강제할 수 있기때문에 앞으로 객체지향언어에서 추천되는 인가 방법이라고 할 수 있다.


다음장은 Spring Security의 Domain ACL에 대해서 알아보도록 하자. (언제가 될지 모르겠다.:)

  1. ACL[에이씨엘]은 개개의 사용자들이 디렉토리나 파일과 같은 특정 시스템 개체에 접근할 수 있는 권한을 컴퓨터의 운영체계에 알리기 위해 설정해 놓은 표라고 할 수 있다. 각 개체는 접근제어목록을 식별할 수 있는 보안 속성을 가지며, 그 목록은 접근권한을 가진 각 시스템 사용자들을 위한 엔트리를 가진다. 가장 일반적인 권한은 1개의 파일이나 또는 한 개의 디렉토리 안에 있는 모든 파일들을 읽을 수 있고(Read), 기록할 수 있으며(Write), 그리고 만약 그것이 실행가능한 파일이나 프로그램인 경우라면 실행시킬 수 있는(Execute) 권한 등을 포함한다. [본문으로]
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기
  1. Favicon of http://minimonk.net BlogIcon 구차니

    2010.07.23 21:05 신고 [수정/삭제] [답글]

    음.. 리눅스에도 ACL이 있는데 그걸 웹으로 확장한건가요? 아니면 이름만 같은 별개의 유래를 가진 녀석일려나요?

댓글을 남겨주세요.

Spring Security - OID, SID, ACL

Posted at 2010.07.23 09:37 // in Principle // by MOOVA 무바㏇
2010:07:23 04:04:12
Figure 1은 OODBMS에 포함된 개념에 대해서 열거한 그림이다.


Spring Security의 Domain ACL의 개념은 Security Identity(SID)라고 하는 객체 보안 식별자에 의해서 인가작업을 하기 때문에, SID의 부모격인 OID(Object Identity)가 무엇인지 알아볼 필요가 있다.


OID를 사용하기 시작한것은 OODBMS에 객체를 식별하기 위한 방법으로 종종 사용하곤 했다. 최근엔 ORM Framework에서 종종 볼 수 있는 Object의 Uniq한 식별자라고 말하기도 하는데, Domain Driven Design의 Eric Evans는 Entities를 정의하면서 Object Identity를 다음과 같이 설명한다.


객체 지향 언어의 Object identity조작은, ENTITY의 identity를 정의함에 있어서 다소 미흡한 면이 많다.
데이터베이스로부터 얻은 Object의 id는 java와 같은 랭귀지의 identity와 는 다르다. 데이터베이스로부터 얻은 객체는 영속성이 있는 반면 프로그래밍언어의 identity는 비영속성이라는 점이 다르기 때문이다. 하지만 데이터베이스와 프로그래밍 랭귀지를 굳이 동기화하자면 특별한 key로 랭귀지 객체에 아이디를 부여하는 것이 일반적이다. 그 identity는 불변하며, 변화될 수 없다. ID는 시스템에 의해서 자동으로 작성할 수 있고 다른 Object와 구별할 수 있는 유일한 식별자가 바로 Object Identity이다.


보통 데이터베이스와 프로그래밍 언어의 동기화를 위해 식별자로 사용된 Object Identity는 Evans가 Entities를 설명하기 훨씬 전부터 정의되어 왔고 변화됐다는 것을 다음의 목록에서 확인하자. (1978년도 이전부터 Object Identity라는 용어가 사용되어왔으니, 필자가 태어나기 이전부터 그 가치가 논의되고 있었다는 소리다. 참.. 놀랍고도 위대하다.)


[각주:1]Khashafian, Copeland (1986) - identity는 Object 내부에 있다. 그것의 목적은 독립적인 Object의 특성을 표현하는데 있다.
Atkinson et al. (1990) - 두 Object가 동일한 제 삼의 Object를 참조할 수 있다. 이것은 공유 Object의 개념으로 Object를 업데이트하거나 조작하거나 카피할 때 Object identity로 그 식별을 대신한다.
Kent (1991) - 다양한 관점으로 Object identity에 대해서 논의했다. Object Identity를 비교하는 것이 아니라 그들을 참조하는 Object에 관점을 두었다. 즉 Object의 실제주소값으로 Object Identity를 설명했다.
Beeri (1993) - 그가 논의했던 OID는 현재 사용되고 있는 Object Identity의 원류가 되었다. identity의 경우에는 그것을 검색하는 쿼리에 따라서 식별된다



발전된 MDA를 채택한 벤더 솔루션중 하나인 Windchill이 사용하는 OID를 잠깐 살펴보자. Windchill내부의 ORM 프레임웍으로 새로운 Entity Object를 생성해 데이터베이스에 객체 저장을 했다. ( Windchill의 영속 객체는 JPA나 HIbernate의 생명주기와 비슷한 그것을 가지고 있다. ) 실제 데이터베이스에 접속하여 OID를 추출해 보면 다음과 같은 형태의 Object Identity를 발견할 수 있다.

-----------------------------------------------------------------------------------------------
Oid
-----------------------------------------------------------------------------------------------
com.tistory.moova.Moovie:001
com.tistory.moova.Moovie:002
com.tistory.moova.Moovie:003
com.tistory.moova.Moovie:004
-----------------------------------------------------------------------------------------------


Evans가 논의한 것처럼 데이터베이스의 식별자와 OOP 언어(자바와 같은)의 식별자는 개념상 다르기 때문에, 도메인에 적합한 OID생성규칙을 사용해서 동기화 하고 있다. 실제로 이것은 Object Identity가 아닌 Object identifier라고 하는 직렬화된 식별자이다.

Figure2. ObjectIdentity와 ObjectIdentifier의 관계도

ObjectIdentity도 Object의 일종으로써 실제 구분할 값을 찾기 위해 ObjectIdentifier라는 직렬화된 식별자를 참조의 형태로 포함하고 있다.(OCP원리를 따르면서 SRP원리도 포함하고 있다.). 실제로 "com.tistory.moova.Moovie:004"와 같은 값을 얻기 위해선 다음의 코드가 필요할지 모르겠다.

..
PersistentHelper.store(moovie);
moovie.getObjectIdentifier() : Serializable

JPA는 @Id, @IdClass, @EmbeddedId로 OID를 활용하고 있으며, Windchill은 Persistent를 상속하는 방법으로 OID를 활용하고 있다.

JPA 예
@Entity
public class Inventory implements Serializable {

        @Id[각주:2]
        @GeneratedValue(generator="InvSeq")
        @SequenceGenerator(name="InvSeq",sequenceName="INV_SEQ", allocationSize=5)
        private long id;

Wnidchill 예
public class Inventory extends Persistent {...}

언어와 플렛폼의 차이를 그대로 보여준다. 하지만, 근본적인 사상과 배경은 같다는 것을 알 수 있다.

이 설명으로 Object Identity와 Object Identifier에 대한 개념은 개략적으로 이해할 수 있으리라 본다. Secure Identity(SID)를 설명하기에 앞서 OID를 설명한 이유는 SID와 OID는 바늘과 실과 같은 수족과 같은 관계이기 때문이다.

보안작업을 하려하는 사람을 예로 들어보자.

예를들어 오승택이라는 사람이 주민등록증이 없으면 보안작업을 할 때 필요한 보안인가증도 발급받을 수 없다. 주민등록은 그 사람을 대표하는 ID이기 때문에, 말 그대로 객체 ID가 없으면 보안인가(SID)에서 필요한 신원을 확인할 수 없다.

충분히 이해가 되었으리라 믿는다. 지금까지의 설명은 Spring Security의 Domain ACL을 설명하기 위한 재료물들이다.




참조 문서

In “The Art of the Interpreter or, the Modularity Complex (Parts Zero, One, and Two)” [75] (1978),
• In “Values and Objects in Programming Languages” [56] (1982), Bruce J. MacLennan discusses the distinction between values and objects.
• The paper “Object Identity” [43] (1986) by Setrag N. Khoshafian and George P. Copeland is the most cited one with regard to the topic of object identity, and gives a thorough presentation of the concept and its implementation in programming languages and database systems.
• In “The Object-Oriented Database System Manifesto” [4] (1990), Mal-colm Atkinson et al. list requirements that are to be fulfilled by object-oriented databases. Of course, object identity plays an important role here.
• “A Rigorous Model of Object References, Identity and Existence” [42] (1991) by William Kent describes a model for object identity that, among other things, aims at a facility for merging objects and their identities after the fact.
• Catriel Beeri criticizes a too strong focus on object-oriented features in the context of databases in “Some Thoughts on the Future Evolution of Object-Oriented Database Concepts” [8] (1993), and sketches a re- duction of the concept of object identity to pure value-based properties in relational databases.
• Roel Wieringa and Wiebren de Jonge present a detailed formal model in “Object Identifiers, Keys, and Surrogates – Object Identifiers Re-visited” [85] (1995) that captures the essential properties of object identity and can be interpreted as the common denominator of previ-ous approaches.



 

  1. http://deposit.ddb.de/cgi-bin/dokserv?idn=972868291&dok_var=d1&dok_ext=pdf&filename=972868291.pdf [본문으로]
  2. http://www.oracle.com/technology/products/ias/toplink/jpa/resources/toplink-jpa-annotations.html [본문으로]
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

효율적인 패턴을 할 때, 연결되었던 이론.

Posted at 2010.01.09 12:37 // in Principle // by MOOVA 무바㏇

학습과 경험의 갭을 줄인다고 한적이 있습니다.
갭이란 이론 따로, 경험 따로아닌 이론을 실체화 할 때 얻을 수 있는 가치에 대한 장점을 말하는 것이었습니다.

아래의 글에서는 이론을 실체화하는 과정을 경험적인 측면에서 나름대로 생생하고 재미있게 표현한 포스트입니다.
이런 창조성패턴은 누군가의 패턴과 비슷해 질 수 있습니다.


http://moova.tistory.com/entry/데이터-흐름에-대한-고찰-아키-패턴
http://moova.tistory.com/entry/데이터-흐름에-대한-고찰-아키-패턴-2





캔트백의 implement pattern - 플러그인 선택 자에서도 명시한 바와 같이 학습을 통한 창조적인 활동은
이미 누군가가 정립해서 내놓은 이론과 닮아갑니다. ( 실제 경험의 한 가지 예를 들었습니다. 이런 연결은 고민을 많이 할 수록 빈번하게 어떤 연결 고리와 만납니다. )
이런 것이 바로 연결 되었다고 하는 것입니다. 학습에 왕도는 없습니다. 주기적인 짧고 긴 반복을 통해 학습을 계속 해 나갈 때 서로 연결되는 부분이 있다면 그 연결고리는 다시 한번 새로운 이론에 연결이 되고 창조되고 소멸됩니다.

이론과 실체의 갭 사이에는 통일성내지는 다양성이 존재한다고 볼 수 있습니다.



한 프로젝트에서 현업을 대상으로 기술 컨설팅을 한적이 있습니다. 한 유지보수 담당자가 심사 숙고해서 짜 놓은 비즈니스 로직에 리펙토링을 한 냄새가 보였습니다.
"XX대리님은 리펙토링 책을 읽지 않아도 리팩토링의 어떤 기법을 사용하셨습니다. 대단하십니다."
라고 칭찬을 해 주었던 적이 있습니다. 열정이 있고 생각이 있는 분이라면 학습을 통하여 미리 있는 패턴과 사상을 알게 모르게 사용한다는 점이 참으로 재미있습니다. 각 조직에서 이런 분들이 한 두 명씩은 있다는 것은 아직 한국의 IT가 희망적인 면이 더 많다는 생각을 하게 됩니다.

이렇게 판단된 시각도 어떻게 보면 지속적인 학습이 있기 때문에 가능하리라 봅니다.



모두 열정적이고 재미있는 IT생활을 하길 바랍니다. 열공하세요.~!

 

저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

4편. About DDD마지막, 그리고 Pluggble System, Eclipse Plugins

Posted at 2010.01.04 19:26 // in Principle // by MOOVA 무바㏇
해당 시리즈는 2009년 8월에 작성된 글입니다. 블로그를 정리하다가 메모성으로 작성한 시리즈를 찾았습니다.

'DDD'에 해당되는 글 17건

  1. 19:24:34 4편. About DDD마지막, 그리고 Pluggble Windchill , Eclipse Plugins
  2. 19:24:10 3편. DDD의 context , 경계와 분할
  3. 19:23:46 2편. About DDD
  4. 19:22:46 1편. Domain Driven Design
  5. 2009/12/30 조커페이스
  6. 2009/12/23 12Manage
  7. 2009/12/15 DDD는 패턴이다.
  8. 2009/12/12 Strategic Domain Driven Design with Context Mapping
  9. 2009/11/15 [DDD] 유비쿼터스 랭귀지의 발견
  10. 2009/06/27 배가 산으로.. 막을 수 있는 방법은? ( Context Map ) (2)


About DDD ( Domain Driven Design ) 4

IV. Strategic Design

EAI나 SOA같이 시스템간의 연계나 대규모의 소프트웨어 프로젝트가 대상이 됩니다.

Strategic Design은 아래의 3개로 구성되어 있습니다.
Context - 타 시스템과의 통합을 , 도메인 모델의 일관성을 유지하면서 실현하는 방법
Distillation - 본질을 추출
Large-Scale Structure - 큰 그림을 팀내 / 팀간에서 공유하기 위한 방법


Context Integration

EAI나 SOA와 같이 복수의 Application을 연게하는 것에서는 문맥의 부정합이 큰 문제가 됩니다. 예를 들어 ERP의 BOM이란 context와 PLM의 BOM이란 context는 목적은 동일하지만 세부적인 기능은 분명 차이가 있습니다. 이렇게 타 시스템과의 통합에서 명확하지 않은 Context를 사용하면 일관성문제나 혼동의 문제가 발생할 수 잇습니다.


Bounded Context Pattern

외부 시스템과의 대규모 연게는 동일하게 사용된 도메인 모델이 존재 하게 됩니다. 1개의 문맥을 사용하더라도 경계가 되는 context내부에서는 의미가 다를 수 있습니다. 그래서 연계팀은 분명한 Context를 정함으로써 팀내에 혼동을 최소한 축소해야합니다. 범위안에 context 를 잘 구분하여 편성하는 것이 좋습니다. (용어사전이라던지, 팀내의 사용되는 단어가 그 범위입니다.)
Continuous Integration pattern

잘 정의된 Context안에서도 다양한 사람들이 작업하고 있으면 점차적으로 모데임 모델을 깨져갑니다. 일관성을 유지하기 위해서 게속적인 통합을 실천합니다. 동일한 context의 표준을 지키고 코드를 주기적으로 빌드하며 , 자동으로 테스트를 합니다. eXtream프로그래밍에서의 CI와 DDD에서의 CI는 본질적으로 차이가 있습니다.eXtream은 코드의 게속적인 통합을 말하고 DDD에서의 CI는 개념의 통합을 중점적으로 생각해야합니다.

CI를 Tool화시킨 솔루션은 다음과 같습니다. : Huson
http://wiki.hudson-ci.org/display/HUDSON/Home

Context Map pattern

Context간의 대응 관계를 말합니다. 각각의 Context에내 사용되는 동일한 도메인이라도 자신의 경계안에서는 사용목적이 다르게 됩니다. 이러한 context의 혼선을 막기위해 Context Map을 활용합니다.
 


Context간에 관계
Shared kernel pattern
팀 혹은 부서간에 공유관리를 의미합니다. 다른 팀과 공유되지 않는다면 독립적인 작업을 수행할 때 분명 다른 팀과의 혼선이 있을 수 있습니다. 공유가 되는 스키마나 도메인 모델이나 소스 코드와 같은것도 공유가 되어야 합니다. 유비쿼터스 언어의 실현을 위해서라도 팀내부 또는 팀 외부간에 적절한 파이프를 연결해야합니다. 독립적으로 어떤 context를 파괴할 때 다른 팀에 초래되는 간섭현상이 생길 수 있습니다. 또한 CI툴을 응용하여 지속적인 통합을 시도하는 것도 중요한 포인트입니다.


Customer/Supplier Development Teams
고객과 공급자 개발팀을 만들어 고객의 참여를 유도합니다.(eXtream) 공급자팀은 수시로 고객과 논의 및 토론(견적이나 기간에 대한 비용, 또는 기타)을 하여 지속적인 통합을 시도합니다.


Conformist Pattern
사용자가 힘을 가지고 있는 팀에서는 고객/공급자의 관계가 잘 구축될 수 없습니다. 일방적인 사용자들의 요구사항이나 이를 무조건 수용하는 태도는 바람직하지 못합니다. 하지만 CI를 활용함으로써 적절한 context내에 지속적인 요구사항을 받아 들일 수는 있습니다. 단 iteration안에서 실행되어야 하고 잘못된 도메인 모델을 설계하더라도 지속적인 통합을 통해 순응자 패턴을 활용할 수 있습니다.



Anticorruption Layer Pattern
기존에 구축한 시스템은 새로운 시스템을 도입할 때 기존 도메인모델에 잘 적용되지 않는 단점이 있습니다. 기존 시스템과 새 시스템간에 (부패방지층)을 마련하고 양방에서 일어나는 변경사항에 대해 관리하고 하는 패턴입니다.
하지만 부패방지층은 비용적인 측면에서 높은 비용을 감당해야 함으로 주의해야 합니다.
(예 : domain convertor, generator, document chaing system)

Separate Ways Pattern
두개의 어플리케이션이 만약 무관하다고 하면 무리해서 통합 하지 앟는 것이 좋다. 전혀
다른 context내에 설치함으로써 독립성을 지킬 수 있다.


Open Host Service Pattern
중간에 공개된 host service를 둠으로써 각 시스템간에 비례를 맞춥니다. 이렇게 프로토콤이 공개된 공유서비스를 활용함으로써 서비스의 기능을 확장하고 싶은 때는 프로토콜을 확장해 나갑니다.

Additional Pattern
Publiched Lanuage pattern
공유된 문서로 context내의 통신을 사용한다.

Distillation
대형 연계 시스템일 수록 연계관리에 혼선이 있는 경우가 종종 발생합니다. 이러한 혼선을 정돈하기 위해서는 중요한 포인트 부분을 추상화해야합니다. 큰 시스템일 수록 잘된 추상화는 여러가지 혼선을 막을 수 있습니다.

도메인의 우선순위
Core Domain Pattern
중요한 도메인을 먼저 분할 정돈합니다. 모든 도메인에서 완벽한 모델을 추출하는 것은 불가능하기 때문에 가장 영향력 있는 중요한 도메인을 중심으로 다른 서브 도메인을 확장해 갑니다. 서브 도메인에서 core domain을 사용하게 되면 도메인간에 상관관계가 깨질 우려가 있으므로 핵심 도메인을 추출하여 프로젝트의 표본으로 삼아야 합니다.


Generic Subdomains pattern
도메인안에는 핵심 도메인이외에 우선순위가 낮은 서브도메인들이 있습니다. 이것은 핵심도메인과 차별화를 하고 우수한 인재들을 서브도메인안에 배치해서는 안됩니다.


Core Domain의 문서화
Domain Vision Statement Pattern
core domain을 문서화하여 프로젝트의 상징이 되도록 해야합니다. 한번에 봐도 전체적인 흐름을 읽을 수 있는 정도의 도메인 비젼 성명 문장을 사용합니다. 간결해야하고 새로운 중심 도메인이 발생했을 때 며확하게 개정해 나가야 합니다.


Highlighted Core Pattern
Domain Vision Statement Pattern을 좀 더 자세하게 기록하고 싶을 때 연결 할 수 있는 다른 document가 필요하게 됩니다.
Highlighted Core Pattern은 다음과 같은 리스트로 정리할 수 있습니다.

1. Core Domain을 간결하게 기술한 가벼운 document를 준비한다.
2. 핵심 도메인에 표시를 붙여감으로써 간결한 문서를 만들어 간다.

추가 : core domain과 sub domain의 상관관계를 문서화 할 수 있는 좋은 툴이 있습니다. Mind Mapper solution이 그 일례입니다. mind mapper는 생각정리의 기술이라는 작은 영역에서 종종 사용되곤 하지만 대규모의 프로젝트에서도 문서상의 상관관계를 잘 도식화 할 수 있는 여러가지 툴이 발전하고 있습니다.



Core Domain의 refectoring

Cohesive Mechanisms pattern

Cohesive mechanisms pattern은 core domain pattern과 generic subdomain pattern에서 의미하는 것과 비슷합니다. 하지만 이것은 솔루션의 범용부분을 추출하는 패턴입니다. 예를 들어서 경량 프레임웍크를 도입해서 도메인으로부터 context를 분리하고 프레임워크가 제공해주는 인터페이스는 의도가 명백한 인터페이스 패턴을 사용해야합니다.generic subdomain pattern은 domain상의 범용부분만 추출하는 것에 비하여, cohesive mechanisms pattern은 솔루션의 범용부분을 추출하는 패턴이라고 할 수 있습니다.
Segregated Core Pattern
core domain안에서 더욱 본질과 관계가 업는 부수적인 부분을 subdomain으로 domain refectoring을 합니다. 본질적인 개념이 상위로 올라가야 하고 중핵으로 부터 서브도메인을 정돈해서 마무리 하는 방법입니다.

Abstract Core Pattern

중복될 수 있는 모듈간에 상호작용이 있을 것 같은 경우, 각 모듈내에 추상화한 모델을 짓고 그것을 새로운 1개의 모듈에 정리합니다. 복수 모듈간에 추상화를 통해서 새로운 core domain을 만들어 냅니다.

Context Map

Evolving Order Pattern

처음부터 대부분의 요구사항을 한꺼번에 받아들여 초반에 한꺼번에 설계하는 것은 불가능합니다. 시스템을 만들면서 조금씩 진화되는 구조로 우선순위를 정해야합니다.대규모의 프로젝트에서는 요구사항이 빈번히 나타날 수 있기때문에 정리 되지 않은 요구사항을 context map기반으로 정리/정돈 해야합니다. 한꺼번에 복잡한 요구사항을 수렴하고 만들어버리게 되면 아무것도 구조를 결정하지 않는것이 더 낳은 방향입니다. 초반부터 막대한 요구사항을 수렴하는 것보다 점증적으로 시스템에 융화될 수 있는 방법이 이 패턴의 핵심입니다. ( Agile관리와 비슷하다. 하지만 명확해야 하는것은 Agile의 점증적인 개발방법론과 어느정도 차이가 있는지 고려해 봐야한다. )

System Metaphor Pattern

참조 : http://www.extremeprogramming.org/rules/metaphor.html



Responsibility Layers Pattern

의사결정 층 : 어떤 전략이나 정책을 실행해야 할지를 결정하는 층

정책 층 : 전략상의 골이나 업무 룰을 실제로 적용하는 층
운용 층 : 일상 행하여 지고 있는 업무를 나타내는 층
업무기반 층 : 어떤 리소스가 있어, 업무상 무엇이 가능한 것일지를 나타내는 층



Knowledge Level Pattern

Analysis Pattern에는 Object를 운용과 지식으로 나누는 패턴이 있습니다. 지식수준의 모델은 운용 수준의 도메인에 관련된 지식을 정의합니다.

참조 : 노나카의 지식변환 프로세스 (http://paradozzz.cafe24.com/blog/?p=161)




DDD의 마지막

Pluggable Component Framework Pattern

착탈식 가능한 프레임워크를 설계하는 것입니다.
착탈가능한 plugin을 말합니다.
한 예로 제조 공정 솔루션인 windchill이라는 솔루션은 이러한 pluggable원칙을 제대로 수용하고 있습니다. OOTB. 추상화된 라이프사이클안에 조립가능한 연결 포인트와 인터페이스를 보장하고 있습니다. Hivemind, Eclipse Plugin구조도 마찬가지겠지요?

신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

3편. DDD의 context , 경계와 분할

Posted at 2010.01.04 19:26 // in Principle // by MOOVA 무바㏇
해당 시리즈는 2009년 8월에 작성된 글입니다. 블로그를 정리하다가 메모성으로 작성한 시리즈를 찾았습니다.

'DDD'에 해당되는 글 17건

  1. 19:24:34 4편. About DDD마지막, 그리고 Pluggble Windchill , Eclipse Plugins
  2. 19:24:10 3편. DDD의 context , 경계와 분할
  3. 19:23:46 2편. About DDD
  4. 19:22:46 1편. Domain Driven Design
  5. 2009/12/30 조커페이스
  6. 2009/12/23 12Manage
  7. 2009/12/15 DDD는 패턴이다.
  8. 2009/12/12 Strategic Domain Driven Design with Context Mapping
  9. 2009/11/15 [DDD] 유비쿼터스 랭귀지의 발견
  10. 2009/06/27 배가 산으로.. 막을 수 있는 방법은? ( Context Map ) (2)


About DDD ( Domain Driven Design )

III. Refactoring Toward Deeper Insight


Specification pattern

Specification pattern :
참조 : http://www.martinfowler.com/apsupp/spec.pdf (읽어봐야 함)


predicate(술어)와 같은 역할을 하는 특수한 Value Object를 도입합니다.
(predicate는 알고리즘의 동작을 정의하는 boolean function을 말합니다)
 isTrue(), isStart() 와 같은 표현은 Entity와 Value Object에 적용할 수 없습니다.
따라서 DDD에서는 Specification pattern을 허용합니다.
Specification pattern은 다음의 3가지로 구성됩니다.

1. Object Validation
2. Object Selection
3. Object Creation




잘된 추상화는 유연한 설계를 보장합니다.

Intention-revealing Interfaces pattern

명확안 interface이름을 사용합니다. 명확하지 않은 interface는 팀내에 개발자들끼리 제대로 된 커뮤니케이션을 할 수 없습니다. 이것은 캡슐화가 정확하게 이루어졌다고 할 수 없습니다. interface에 명확한 이름을 사용함으로서 도메인 모델의 유비쿼터스 언어를 따르도록합니다. 그리고 가능한  TDD를 선행해야합니다.


Side-Effect-Free Functions pattern

side effect :
부작용은 function을 수정하거나 인자를 수정하거나, 다른 부작용이 있는 function을 호출할 때, 또는 실행할 때 나타납니다. 부작용은 과거에 히스토리와 관련이 되어 있습니다. 이해하기 쉬운 프로그램은 과거의 히스토리를 쉽게 나타낼 수 있어야 합니다. 부작용이 있는 히스토리는 프로그램을 종종 더 어렵게 만들곤 합니다.

부작용 없는 함수로 프로그램화하고, 상태를 변화시키는 조작을 최소로 해야합니다. value object는 상태가 변함이 없습니다



Assertions pattern

side-effrect-free functions pattern을 사용하면 부작용을 최소화 할 수 있습니다. 하지만  pattern을 사용하더라도 부작용은 어딘가에 있기 마련입니다.나머지 부작용을 쉽게 조작하기 위해서 assertion을 사용합니다. Assertions pattern은 Design by contract를 기초로 하고 있습니다.



분할이 잘된 설계는 유연한 설계의 기초석입니다.

Conceptual Contours pattern

High cohesion을 잘 나타내기 위해서는 냄새가 날 때마다 refectoring을 해야합니다. 기능이 분산되어 응집이 낮은 곳에 주기적인 refectoring을 하여 개념을 분리하고 높은 응집을 통해 개념의 윤곽을 나타내야합니다. High cohesion은 General Responsibility Assignment Software Patterns (GRASP)에 기초를 두고 있습니다.


Standalone Classes pattern

class들도 독립적인 개념을 가져야 합니다. Low Coupling pattern으로 설명하고 있습니다. 각 클래스간에 의존도가 독립적이면 확장이나 재사용에도 좋은 클래스들의 집합군을 만들 수 있습니다. 예를 들어 디자인 패턴중 Strategy pattern을 적극 활용하면 시스템에 종속적인 상속을 통한 확장 이 외에 구성을 통한 확장을 조합해서 활용할 수 있습니다. 디자인 패턴중 확장의 원리가 전역으로 활용된 SpringFramework가 그 예입니다.


Closures of Operations Pattern

operator에서 사용되는 인자나 리턴값들을 primitive type으로 지정하게 된다면 또다른 의존도를 발생시킬 우려가 있습니다. 메소드에 특정한 object를 넘겨주고 return값도 동일한 object type으로 되돌려 주는 패턴을 말하고 있습니다. 다음의 문서를 참조하세요

1. Martin Fowler와 Evans의 (fluent interface) 참조 ,

2. Builder pattern 참조 ,



3. DomainSpecificLanguage 참조

신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

2편. About DDD

Posted at 2010.01.04 19:26 // in Principle // by MOOVA 무바㏇

해당 시리즈는 2009년 8월에 작성된 글입니다. 블로그를 정리하다가 메모성으로 작성한 시리즈를 찾았습니다.

'DDD'에 해당되는 글 17건

  1. 19:24:34 4편. About DDD마지막, 그리고 Pluggble Windchill , Eclipse Plugins
  2. 19:24:10 3편. DDD의 context , 경계와 분할
  3. 19:23:46 2편. About DDD
  4. 19:22:46 1편. Domain Driven Design
  5. 2009/12/30 조커페이스
  6. 2009/12/23 12Manage
  7. 2009/12/15 DDD는 패턴이다.
  8. 2009/12/12 Strategic Domain Driven Design with Context Mapping
  9. 2009/11/15 [DDD] 유비쿼터스 랭귀지의 발견
  10. 2009/06/27 배가 산으로.. 막을 수 있는 방법은? ( Context Map ) (2)



Windows Live Writer로 작성한 글입니다. – moova remote

About DDD

1. Putting the Domain Model to Work

Ubiquitous Language pattern

도메인중심의 소프트웨어 팀에서는, view(사용자,도메인전문가,설계자,프로그래머,분석가,설계자)간에 동일한 의미를 지닐 수 있는 공통된 언어가 필요하다. 모든 이해 당사자들이 같은 의미, 심지어는 소스코드까지 통일된 의미로 이해되는 것이  Ubiquitous language 에 기본 사상이다. 도메인중심의 시스템이 유비쿼터스 언어가 되도록 노력하고, 해당 언어가 프로젝트 전체를 일체화 시키도록 노력해야 한다.

Model Driven Design pattern

Ubiquitous Language를 실현하기 위해서는, 코드레벨에서부터 도메인 모델까지 정확하게 표현되어 있지 않으면 안 된다. 도메인모델을 변경하면 바로 코드로 적용되어야 하고, 반대로 코드가 변경되면 도메인모델에도 반영이 되어야 한다(역공학) 코드와 긴밀히 결부시키는 것이 모델 구동 설계라 한다.(MDD) , 때에 따라서는 RUP의 MDA체제를 비교해보면 얼추 흡사하다. 하지만 MDA는 MDD의 상위 개념이므로 실현할 수 있는 Tool과 실전경험, 예제를 분석하여 제조뿐만이 아닌 응용영역에서도 활용할 규칙을 찾아야 한다.

Hands-On Modeler pattern

시스템 구축에 직접적으로 참여하는 당사자들(모델러,프로그래머,설계자)간에 모델표현기술과(UML) 프로그래밍 언어가 공유되어야 한다. 모델러가 프로그램언어를 이해하지 못한다거나, 프로그래머가 모델링을 이해 하지 못하면 Hand-On Modeler pattern을 실현 할 수 없다.

즉. 팀 내의 모든 개발자는(설계자,프로그래머,모델러)는 상위 모델부터 하위 언어까지 이해해야만 한다.

2. Building Blocks of a Model-Driven Design

Layered Architecture pattern

UI(User interface)와 모델이 결합되어 있으면, 잦은 UI변경이 일어날 때 모델의 변경도 잦게 된다. MDD를 실천하기 위해서는 UI와 비즈니스로직 그리고 모델링간에 구별할 수 있는 층을 만들어야 한다.추상 기준에 따라 얼마나 많은 추상 레벨로 나눌지를 결정하고, 각 레이어마다 역할을 부여하고 각 에리어에 태스크를 할당해야 한다.(POSA)  Layered Architecture의 잠점은 다음과 같다.

1. 레이어를 재사용할 수 있다.
2. 표준을 지원한다.
3. 종속성을 국지적으로 최소화 한다.
4. 교환가능성이 확보된다.
5. 동작이 변경될 경우 단계별로 재작업이 필요하다.

Layered Architecture를 가장 잘 표현한 구조는 네트워크 프로토콜과 자바 VM 그리고 API기반기술이다. DDD에서 말하는 Layered Architecture는 소프트웨어 영역의 4계층으로 나누는 것으로 정의된다.

1. UI area
2. Application area
3. Domain area
4. Infrastructure area

위의 4분류는 상위부터 하위까지 층을 이루어 건설하는 기본이 깔려있다.

Smart UI anti pattern

유일하게 DDD pattern중에서 anti pattern이 이것이다.Layerted Architecture와 정반대의 개념을 가지고 있는 이것은 UI와 비즈니스 로직, 그리고 도메인 모델이 일체화 되어 운용된다. Smart UI pattern을 도입하게 되면 모든 처리가 UI 중심으로 연결되어 진행되기 때문에 제대로 된 설계가 없으면 DDD는 실현될 수 없다. 예를들어서 .net 2.0이상에서 이지윅방식으로 소프트웨어를 생산하는 체제가 바로 이 Smart UI pattern이다. (.net2.0이 나쁘다고 하는 것은 아니다. 단, DDD에서 Smart UI를 채용하면 독이 될 수 있다는 것을 말하고 싶다. – 닷넷하는 친구가 오해 할까 봐서리..)

Entities pattern

ID를 가지는 Uniq한 Object이다. identity가 같으면 속성이 다르더라도 동일한 것으로 취급 해야 한다. 반대로 ID가 틀리면 모든 속성이 다르더라도 각각의 entity로 취급 해야 한다.

이것은 Uniq key 또는 UI와도 비슷하며 Object Reference를 경유한 Object identification 를 추상화한 제품에서 찾아볼 수 있다.

Value Objects pattern

색이나 돈의 양, 그리고 단순한 state가 있는 속성은 entity가 아니다. 이것은 primitive형과 닮았으며, 단순하게 성질을 표현 하는 것이다. Entities pattern을 상위로 Value Objects pattern은 유지하도록 한다.

Services pattern

DDD에서 서비스는 기능을 처리하거나 Entity로 구별할 수 없는 것을 말한다. Layered Architecture pattern에서 Service 계층을 구별하는 것도 좋은 방법이지만 DDD에서는 Domain 모델안에 있는 서비스적인 것을 말한다.

A standalone operation within the context of your domain. A Service Object collects one or more services into an object. Typically you will have only one instance of each service object type within your execution context

Modules pattern

Module은 리펙토링과 에자일에 의해 진행되어야 한다. 모든 것은 하나의 응집체로 보지 않고, 높은 응집과 낮은 결합도에 따른 설계사상을 포함 해야 한다. java에서 Modules pattern을 가장 잘 나타낸 시스템은 JSR-277 spec에 나와있다.
(http://www.parleys.com/display/PARLEYS/JSR-277+Java+Module+System)

Aggregates pattern

Object의 연관은 집약되어야 한다. Component Diagram을 보면 외부에 노출되는 Interface, 또는 외부 도메인과 연결하는 통신Root를 말한다. 외부에서 Object의 그룹을 접근하면 기본이되는 interface나 root로 통신 해야 한다. 이렇게 Object로 만들어진 그룹은 그 그룹을 대표하는 Root를 지정함으로써 더 집약되어 진다.

Factories pattern

Root가 되는 그룹이나 단일 Object는 그것을 생성처리 하는 행위가 정체성 없이 흩어질 수 있기 때문에 Factory를 도입해서 정리할 수 있다. Factory method pattern이나 spring에서 쓰는 @Configuration 이 DDD의 Fatories pattern과 비교할 수 있다.

Repositories pattern

factory에서 생성된 Object는 자기 운명이 있다. 이것을 일종의 Object lifecycle이라 하는데 가령 Entity를 예로 들자면 Entity가 생성되고, 정보가 DB에 저장되고,파멸 될 때 까지 자기만의 lifecycle이 있다. 그러한 생명주기가 흩어 지지 않도록 각 모델안에는 Repository라고 하는 외부 접속에 필요한 object가 준비되어있다. 

The Repository pattern is a Persistence abstraction in Domain Driven Design

 

3. Refactoring Toward Deeper Insight

신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

1편. Domain Driven Design

Posted at 2010.01.04 19:25 // in Principle // by MOOVA 무바㏇
해당 시리즈는 2009년 8월에 작성된 글입니다. 블로그를 정리하다가 메모성으로 작성한 시리즈를 찾았습니다.

'DDD'에 해당되는 글 17건

  1. 19:24:34 4편. About DDD마지막, 그리고 Pluggble Windchill , Eclipse Plugins
  2. 19:24:10 3편. DDD의 context , 경계와 분할
  3. 19:23:46 2편. About DDD
  4. 19:22:46 1편. Domain Driven Design
  5. 2009/12/30 조커페이스
  6. 2009/12/23 12Manage
  7. 2009/12/15 DDD는 패턴이다.
  8. 2009/12/12 Strategic Domain Driven Design with Context Mapping
  9. 2009/11/15 [DDD] 유비쿼터스 랭귀지의 발견
  10. 2009/06/27 배가 산으로.. 막을 수 있는 방법은? ( Context Map ) (2)

도메인 모델이란 무엇인가?

생각해봐야 할 부분은 소프트웨어에서 사용하는 모델은 무엇인가? 라는 점이다. 대게 모델이란 용어는 소프트웨어 영역을 벗어날 때 , 더 다양한 의미로 사용되곤 한다.

모델
1. 예술가를 위해 포즈를 취하는 사람
2. 미니어처같은 작은 빌딩 구조물
3. 하나의 아이디어가 선택되서 예제로 쓰일 때
4. 비즈니스 모델.
5. 사이버 모델.

일상에서 사용되는 모델의 용도를 나열해 봤다.
위의 공통점을 뽑아보면 모델이란 '현실에 존재하는 추상화된 무언가' 로 정의 내릴 수 있다.

반면 소트프웨어에서 사용하는 모델이란 '객체, 시스템, 또는 개념에 대한 구조나 작업을 보여주기 위한 패턴, 계획, 또는 설명이다' 라고 정의되어 진다.(wikipedia)

그렇다면 도메인이란 무엇인가?

넓은 의미로는 네트워크 상에서 컴퓨터를 식별하는 호스트명을 말하며, 좁은 의미에서는 도메인 레지스트리에 등록된 이름을 말한다. application 영역에서는 도메인이란 다음과 같이 정의되고 있다.
  • An application area
  • A business area
  • A software business area
  • A software intensive application area
  • An application area for which similar software systems have been built

소프트웨어에서 도메인이란 '영역' 이란것을 짐작 할 수 있다.
일반적으로 영역이라 하면.. 일종의 경계, 선 긋기라는 용도로 이해해도 될 것 같다.

그렇다면. 소프트웨어에서 사용하는 도메인 모델이란?

'시스템 영역간에 객체,시스템, 또는 개념에 대한 구조나 작업을 보여주기 위한 패턴,계획 또는 설명이다' 라고 압축할 수 있다. 하지만 실제로 도메인 모델은 다음과 같이 정의된다.

도메인 모델

A domain model, or Domain Object Model (DOM) in
problem solving and software engineering can be thought of as a conceptual model of a system which describes the various entities involved in that system and their relationships.



서론이 너무 길었다.
DDD에서 사용하는 Domain Model이란 위에서 정의된 것을 베이스로 몇가지 요점을 정의할 수 있다.

1. 도메인 모델은, 도메인 지식을 깊게 하면서 반복적 (iterative)으로  심화시켜 간다
2. 도메인 모델은 개발자와 도메인 지식을 가지는 사람(전문가등..)과의 공통 언어가 되도록 한다
3. 도메인 모델과 구현 코드가 정확히 연계 할 수 있도록 한다

기타 DDD에서 사용하는 도메인층의 분리와 도메인 구성 요소(entity,Value object,services,modules), 라이프사이클(aggregates,factories,repositories)의 사전지식이 필요하다.
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

아바타

Posted at 2010.01.03 20:14 // in Principle // by MOOVA 무바㏇
최고였다.



I wanna fly with you.
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

데이터 흐름에 대한 고찰 - 아키 패턴 1부

Posted at 2009.04.08 04:38 // in Principle // by MOOVA 무바㏇

전형적인 SI에 '아키 패턴'을 도입하면 과연 효율적으로 관리가 가능할까?

수시로 변경되는 요구사항속에서 우리내 개발자들은 악전고투하며 월화수목금금금을 지새고 있다. 열정이 있는 사람들도 앞으로 누군가가 잡아주길 원하고 제대로 된 멘토링을 받길 원하지만 ..우리의 고귀하신 SI도급체계는 그들의 꿈마저 시간이란 제약속에 묶어놓고 있다.
이런 분위기가 과연 한쪽만의 책임으로 몰아갈 수 있는가?  만약에 그렇지 않다면 우리는 우리가 가져야 할 기본적인 것 조차 잊은채 살아가지는 않나..

SI현장에선 항상 보이는 모습이 있다. '바로 요구사항 때문에..'라는것이다.
요구사항이 변경되었기 때문에 더해가는
경직성, 부동성, 불필요한 복잡성...그리고 결국은
불투명성까지 난잡한 상황이 비일비재하다.

하지만 보자.. 요구사항은 항상 변한다는 진리가 있다. 요구사항은 언제나 변하기 마련이다.
물론 처음에 요구사항은 정말 제대로 이다. 멋들어지게 SRS를 꺼내놓고 멋들어지게 분석과 설계를 하여 일련의 프로세스와 방법론을 사용한다고 말한다. SRS도 일단은 현실에선 엑셀리스트에 보여주기 위한 방편이지만 말이다..


풍자 : 소프트웨어 개발의 지혜 - 로버트 C,마틴 의 일부를 응용했다.

요구사항 : 현재의 페이지에 프린터로 복사하는 프로그램을 작성하라

초반에 요구사항은 위에서 보는것처럼 정말 단순하다. 단지 1시간만에 설계와 개발을 끝낼 수 있을 것 같다. 하지만 품질교육, 미팅, 파트별 미팅까지 합한다면 아마..3~4시간 걸릴 일일 수도 있다.
 


public class PagePrinterImpl {
       public void print(PageContext context){
         PageBuffer buffer = PageBuffer(100);
         while( context.available() != 0)   {
               buffer.add( context.readLine() );
         }
         PrintOSXWriter .print( buffer );
      }
}

위와같이 작성한 설계자와 개발자는 배를 두드리며, 이것은 더이상 할게 없다고 안심을 한다.
하지만 일주 뒤 상사가 와서 요구사항이 바뀌었다고 한다.

요구사항 : 프린터기능에서 미리보기를 넣어달라.
이미 인터페이스까지 설계한 설계자는 안된다고 피력한다.

사용자 삽입 이미지

왜냐하면 프린트 프로그램은 애초에 미리보기 기능이 없었던 프로그램이다.! 인터페이스를 변경하면 그동안 해왔던 테스트와 컴파일,배포과정을 다시 반복해야 한다. 그럼에도 불구하고 상사는 원고하다. 정말로 사용자들이 미리보기를 원한다는 것이다.


public class PagePrinterImpl {
private boolean printStyle = false; // 이 플래그는 바뀔 수 있음.

       public void print(PageContext context){
         PageBuffer buffer = PageBuffer(100);
         while( context.available() != 0)   {
               buffer.add( context.readLine() );
         }
         if( printStyle  )
            PrintOSXWriter .print( buffer );
         else
            PrepareOCXWriter.print( budder );

      }
}


개발자( 이곳에서 말하는 개발자란 , 디자이너, 설계자,분석가, 개발자, 모두를 포함한다.)
는 성공적으로 코드를 검증했다. 그리고 고객의 칭찬을 받는다. 흐뭇해 하며 집에 일찍 퇴근할 결심을 한다.

한주가 지났다. (수개월에 걸친 세 번의 전사적 구조조정 후에도 아직 여러분의 상사가 나타났다. ) 그 상사는 고객이 일반 프린터 뿐만 아니라 PDF출력까지 고객이 요구했다는 것이다.

고객이란!

사용자 삽입 이미지


그들은 항상 우리의 설계를 망치고 있다. 아마도 업무를 제대로 모르는 현업을 생각하지 않고 프로그램을 만들어서 제안을 했다면 그것이 월등히 나은 제품을 만들 수 있을 것이다.



요구사항 : PDF출력까지 해야함

개발자는 말한다. 이런식으로 계속 요구사항이 바뀌면 소프트웨어는 아마 유지보수하기 불가능 하게 될 것이라고 다이어그램을 펼치며 설명한다. 상사는 이해했다는 제스추어와 함께 일단은 고객이 요구하니 변경을 해 달라고 말한다.


public class PagePrinter{
       // 이미 미래를 예측했다. 하지만....
       // private boolean printStyle = false; // 이 플래그는 바뀔 수 있음.
       
      private static String PRINTSTYLE; // 새로운 플래그다. constants가 매번 바뀔 수 있다.
       
       public void print(PageContext context){
         PageBuffer buffer = PageBuffer(100);
         while( context.available() != 0)   {
               buffer.add( context.readLine() );
         }

         /*
         if( printStyle  )
            PrintOSXWriter .print( buffer );
         else
            PrepareOCXWriter.print( budder );
         */
         
          if(PRINTSTYLE.equals("PRINT") ){
            PrintOSXWriter .print( buffer );
          }else if(PRINTSTYLE.equals("PREPARE") ){
            PrepareOCXWriter.print( buffer );
          }else{
            PDFOCXWriter.print(budder);
          }

      }
}


뭔가 슬슬 불안에 지기 시작했다. 만약에 또 이곳에 변경이 생긴다면 LOC만 증가할뿐이고 불필요한 주석문만 난잡하게 늘어날 것이다. 그럼 인수인계는 어떻게 하지? 초반에 멋들어지게 설계한 그것이 가면갈수록 인수인계하기 쪽팔린 무엇이 되어가고 있다.

무엇이 우리를 불안하게 만드는가?  과연 초반 설계를 완벽하게 했다고 할 수 있는가?
SI에서 나타나는 매번 저런식의 업무는 우리의 고귀하신 책들까지 완전히 무시해 버리고 말았다. 참을성이 늘어간다. 아마 또 요구사항이 나오면 후배에게 인계해줄 쪽팔린 설계문서를 던져놓고 먼지를 털 수도 있을 것이다.

하지만 미래를 예측하면! 저렇게 불안해 할 필요가 없다!
(실례) -- 2부로....

신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

티스토리 툴바