드디어 책이 출판되었습니다.
- Posted at 2005/12/23 11:47
- Filed under Program/book
1년 동안의 집필 과정으로 통해 드디어 출판되었습니다.
개인적으로는 두번째 책입니다. 2004년 겨울 정도에 출판 되었으면 더 좋았을 것이라는 아쉬움이 있지만...
책의 주요 내용은 객체지향으로 분석설계된 도메인 모델을 어떻게 POJO로 구현할 것인가에 대한 내용입니다. OR Mapping 관련 구현 기법 등에 대해 많은 부분을 설명하고 있습니다.

머리말에도 언급하고 있지만 책의 내용 중 일부는 현재 관점에서는 틀린 내용도 있을 수 있고 더 좋은 기법이 있을 수 있습니다. 책으로 출판하면서 책에 일부 오류가 있다고 하는 것은 독자에 대한 집필자의 책임이 아닌 줄 알지만 빠르게 변화고 있는 기술환경에서는 어쩔수 없다라고 변명을 해봅니다. 의견이 있으신 분들은 언제든지 메일 또는 블로그에 남겨 주세요.
목차
패러다임의 변화
- 도메인 모델(Domain Model)
- 도메인(domain)
- 도메인 모델(domain model)
- object vs. table
- 도메인 모델의 장/단점
- Emp, Dept 도메인 객체
- 도메인 객체를 이용하는 클라이언트
- O-R(Object-Relational) Mapping
도메인 객체 로딩
- 구조적 프로그래밍 vs. 객체지향 프로그래밍
- 연관관계 객체의 로딩(JOIN)
. 도메인 객체의 equals() 메소드
. Mapper(Data Access Object)
. DomainKey 클래스
. DomainObject 클래스
. DBMapper
. 객체는 유일해야 한다
. 트랜잭션
. 트랜잭션 관리와 객체 Pool
. 1:N 관계 로딩
. AssociationLoader
. JOIN 로딩의 문제점
. JOIN 로딩 정리
- 연관관계 객체의 로딩(CASCADE)
- 연관관계 객체의 로딩(Lazy 로딩)
. VirtualList
. 1:1 관계에서의 lazy load
객체 대 테이블 매핑
- 기본 매핑
. 하나의 테이블로 매핑(Single Table)
. FK를 이용한 매핑
- 상속관계매핑
. 모든 클래스를 하나의 테이블(One table for all classes)
. 하나의 클래스에 하나의 테이블(One table for one class)
. 하나의 구체화된 클래스에 하나의 테이블(One table for one concrete class)
- 연관관계매핑
. FK를 이용하여 매핑
. 연관관계 테이블 이용 매핑
게시판 로딩 구현
- 답변형 게시판 설계내용
- 객체-테이블 매핑
- 개발 환경 구성
- 구현을 위한 클래스 다이어그램
- User, Board
- Article, ArticleFile
- 상속 관계의 Mapper
- Article User 관계설정
- Article ArticleFile 관계 설정
- TopArticle Board 관계 설정
- ReplyArticle Article 관계 설정
- 게시글 목록조회
- 게시글 상세조회
객체의 저장
- 객체의 트랜잭션 처리
- 객체의 생성
. 트랜잭션 Pool
- 트랜잭션의 시작/종료/오류
. TxAdapter
. DBMapper의 insert 기능
. TxManager의 트랜잭션 종료 처리
- 객체의 수정
. Dirty flag
. 수정 기능 추가의 편의성
. 1:1 연관관계 수정(Emp Dept)
. 1:N 연관관계 수정(Dept Emp)
. AssociationMapper를 이용한 연관관계 Update 처리
. DomainList
. AssociationList
. 1:N 연관관계에서의 객체 생성(Dept Emp에서 Emp 생성)
. 1:N 연관관계에서의 객체 생성(Dept Emp에서 Dept 생성)
. VirtualList
- 객체의 삭제
- N:N 관계에서의 연관관계 저장
- 양방향 관계에서의 수정/삭제 처리
- 저장소가 DBMS가 아닌 경우 Persistency 계층 구성(SAP/R3)
게시판 적용
- 객체의 로딩
- 게시글 등록
- 게시글 수정
- 게시글 삭제
도메인 모델을 이용한 컴포넌트 개발
- 컴포넌트란?
. 재사용성
. 대체가능성
. 독립기능성
. 구현 관점에서의 컴포넌트
- CBD 방법론
- 컴포넌트 개발
. 컴포넌트 식별
. 컴포넌트 인터페이스 정의
. 컴포넌트 설계
. 애플리케이션 설계
. EJB 컴포넌트
. 컴포넌트 운영 환경(CEE, Component Execution Environment)
. Runtime Object Type Binding
. Deployment Descriptor
. 컴포넌트 구현
. 화면 계층은 컴포넌트 내부인가? 외부인가?
. 컴포넌트에서의 성능문제
. 다른 컴포넌트로 대체
. 컴포넌트의 테스트
. 컴포넌트 패키징
- 컴포넌트 내부 구현
프리젠테이션 계층
- JSP Model2(MVC 패턴)
- Struts
. Struts Model
. Struts View
- JSP Model2 프레임워크 만들기
. FrontController 구현
. Action 구현
. JSP Model2의 문제
- 소스 생성 도구의 사용
컴포넌트 제작 사례
- ACL 관리(Access Control List) 컴포넌트
. 도메인 분석
. 설계
. O-R 매핑
. 구현
. 다른 시스템에 적용하기
. WebServices로 전환하기
개인적으로는 두번째 책입니다. 2004년 겨울 정도에 출판 되었으면 더 좋았을 것이라는 아쉬움이 있지만...
책의 주요 내용은 객체지향으로 분석설계된 도메인 모델을 어떻게 POJO로 구현할 것인가에 대한 내용입니다. OR Mapping 관련 구현 기법 등에 대해 많은 부분을 설명하고 있습니다.

머리말에도 언급하고 있지만 책의 내용 중 일부는 현재 관점에서는 틀린 내용도 있을 수 있고 더 좋은 기법이 있을 수 있습니다. 책으로 출판하면서 책에 일부 오류가 있다고 하는 것은 독자에 대한 집필자의 책임이 아닌 줄 알지만 빠르게 변화고 있는 기술환경에서는 어쩔수 없다라고 변명을 해봅니다. 의견이 있으신 분들은 언제든지 메일 또는 블로그에 남겨 주세요.
머리말
책의 주요 내용은 EJB를 이용하지 않고 순수자바객체(POJO, Plain Old Java Object)를 이용하여 컴포넌트를 구현하는 방법에 대해 설명하고 있다. POJO를 이용하여 컴포넌트 내부를 구성하는 방법에는 많은 방법을 사용할 수 있지만 본 글은 도메인 모델의 구축과 그것에 대한 구현을 주제로 하고 있다. "도메인모델"이라는 용어를 처음 접하는 독자들은 객체지향에서 말하는 클래스, 상속, 객체와의 관계를 이용해서 시스템 대상 업무를 모델링 한 것이라고 생각하면 된다. POJO로 컴포넌트를 구현하기 위해서는 객체지향적인 구현 기법을 익히는 것이 필수이기 때문에 글의 대부분의 내용은 객체지향을 이용하여 엔터프라이즈 애플리케이션을 구현하는 방법에 집중하고 있다.
많은 책들이 EJB 또는 컴포넌트를 설명하고 있지만 컴포넌트 기반으로 이동하는 전 단계인 객체지향의 구현 방법에 대해 설명하고 있는 책들은 많지 않다. 객체지향적 사고나 구체적인 구현 기술에 대한 가이드가 없다면 방법론 자들이 주장하는 컴포넌트 기반 개발의 모든 내용들은 허구에 지나지 않을 것이다. 필자는 컴포넌트 기반 개발 방법을 평가 절하하려는 것이 아니라 컴포넌트를 도입하기 위해 우리의 개발조직, 개발자의 역량은 성숙되었는지에 대해 의문을 제기하는 것이다.
객체지향은 복잡한 비즈니스를 이해하기 쉽게 접근하고 구현할 수 있는 방법을 제시하고 있다. 그리고 과거 몇 년 동안의 노력으로 이제 객체지향 기술은 엔터프라이즈 시스템에 적용하기에 충분하고 이미 많은 사이트들이 객체지향을 이용하여 구축되었으리라고 생각한다. 이런 기술적인 성숙에도 불구하고 국내에 나와 있는 대부분의 책들은 EJB의 스펙만을 설명하거나 각종 프레임워크에 대한 사용 매뉴얼(user's guide) 수준으로 언급된 내용들뿐이다. 객체지향 기술을 기업의 엔터프라이즈 애플리케이션에 적용하기 위해서는 모델링 기법, 객체와 관계형 데이터베이스의 매핑 기법, 각종 패턴의 활용, 성능과 관련된 문제 등 많은 내용들을 이해해야 한다. 이런 기술적인 성숙에도 불구하고 아직 해결되지 않는 많은 문제들이 있다. 이런 문제를 해결하기 위해서는 개발자 스스로가 다양한 사례와 이론들을 공론화하고 토론해야 하지만 아직까지 국내 객체지향 개발 커뮤니티는 이런 단계까지는 진행하지 못한 것 같다.
이 글의 내용은 객체지향을 이용한 엔터프라이즈 애플리케이션 구축과 관련하여 소스 레벨에서의 구현과 관련된 주제를 다루고 있다. 글을 읽는 독자들에게는 조금 미안하지만 글에서 주장하는 많은 내용들이 틀릴 수 있고 이미 누군가 만들어서 사용하고 있는 것일 수 있다. 하지만 이 글을 통해 여러 개발자들이 토론할 수 있는 기본적인 자료가 되었으면 하는 것이 필자가 글을 쓰기로 결심한 이유임을 이해해 주기 바란다.
필자가 처음 객체지향 기법을 접하고 엔터프라이즈 애플리케이션에 적용하고자 했을 때에는 이것은 풀 수 없는 수수께끼의 연속 같았다. 하나를 해결하면 또 다른 수수께끼가 나타나고, 외국의 웹사이트 또는 여러 참고 서적에 흩어져 있는 조작들을 모으고, 그래도 없는 부분은 직접 만들어서 붙이고 하는 작업의 반복이었다(외국의 많은 사이트의 경우 전체 소스를 공개해 놓은 사이트는 매우 드물었다). 이것은 너무 고통스러운 작업이었으며 프로젝트를 진행하면서 퍼즐을 맞춘다는 것은 거의 불가능의 작업이었다. 약 2년에 걸친 조각 맞춤이 지난 후에야 실제 사용할 수 있을 정도의 모습이 나타났으며 아직까지 이 조작 맞춤은 진행형이라고 할 수 있다.
최근에는 Hibernate, ibatis, TopLink 등과 같이 많은 O-R 매핑 도구가 나타나고 있으며 이들이 주장하는 것은 이제 더 이상 O-R 매핑 도구는 프로젝트 자체에서 만들 필요가 없다고 한다. 물론 이것은 맞는 말이다. 여러 사이트에서 검증된 좋은 도구들이 많은데 굳이 새로운 것을 만들 필요는 없다. 하지만 그러한 도구들을 사용하는 개발자들이 O-R 매핑에 대한 개념을 충분하게 이해하지 못한 상태에서 사용했을 때에는 더욱 심각한 문제를 초래할 수 있다. 이 책에서는 O-R 매핑 도구를 만들어 가면서 왜 이러한 기능들이 필요하며 어떻게 사용해야 하는지에 더 많은 의미를 두고자 한다.
이 글은 현재 자바를 이용하여 엔터프라이즈 애플리케이션을 개발하고 있거나, 이미 개발된 시스템을 유지보수 하고 있는 개발자를 대상으로 하여 작성하였다. 따라서 글의 내용을 이해하기 위해서는 Java 언어의 기초 지식과 J2EE 중 JSP & Servlet, 그리고 JDBC와 같은 기본적인 개념은 이해하고 있어야 한다. 하지만 EJB에 대한 사항은 자세하게 알지 못해도 글의 내용을 이해하는데 어려움은 없을 것이다.
책이 초반부에는 TDD(Test Driven Development) 기법을 적용하여 테스트 코드를 먼저 만들고 실제 코드를 만드는 방식으로 전개하고 있다. 이것은 동일한 기능을 수행하는 코드를 다양한 방식으로 접근해보고, 각각의 장점과 단점을 이해하는 방식으로 진행되기 때문에 변경된 코드의 정상적인 기능 수행여부를 확인하는 방법으로 TestCase를 사용하고 있다. 책의 후반부로 넘어갈수록 필자는 TDD를 사용하지 않는데 이유는 복잡해지는 프로그램에 대한 테스트 코드 작성의 경험부족이다. 테스트 코드에 대한 경험이 없는 내용을 활자화한다는 것에 대한 두려움으로 뒷부분에서는 테스트 코드의 작성을 포기하였다. 하지만 분명하게 강조하고 싶은 것은 이것은 필자의 경험의 부족으로 인한 것이지 결코 자동화된 테스트 코드를 만드는 것이 어려워서가 아니라는 것을 밝혀두고자 한다.
책의 주요 내용은 EJB를 이용하지 않고 순수자바객체(POJO, Plain Old Java Object)를 이용하여 컴포넌트를 구현하는 방법에 대해 설명하고 있다. POJO를 이용하여 컴포넌트 내부를 구성하는 방법에는 많은 방법을 사용할 수 있지만 본 글은 도메인 모델의 구축과 그것에 대한 구현을 주제로 하고 있다. "도메인모델"이라는 용어를 처음 접하는 독자들은 객체지향에서 말하는 클래스, 상속, 객체와의 관계를 이용해서 시스템 대상 업무를 모델링 한 것이라고 생각하면 된다. POJO로 컴포넌트를 구현하기 위해서는 객체지향적인 구현 기법을 익히는 것이 필수이기 때문에 글의 대부분의 내용은 객체지향을 이용하여 엔터프라이즈 애플리케이션을 구현하는 방법에 집중하고 있다.
많은 책들이 EJB 또는 컴포넌트를 설명하고 있지만 컴포넌트 기반으로 이동하는 전 단계인 객체지향의 구현 방법에 대해 설명하고 있는 책들은 많지 않다. 객체지향적 사고나 구체적인 구현 기술에 대한 가이드가 없다면 방법론 자들이 주장하는 컴포넌트 기반 개발의 모든 내용들은 허구에 지나지 않을 것이다. 필자는 컴포넌트 기반 개발 방법을 평가 절하하려는 것이 아니라 컴포넌트를 도입하기 위해 우리의 개발조직, 개발자의 역량은 성숙되었는지에 대해 의문을 제기하는 것이다.
객체지향은 복잡한 비즈니스를 이해하기 쉽게 접근하고 구현할 수 있는 방법을 제시하고 있다. 그리고 과거 몇 년 동안의 노력으로 이제 객체지향 기술은 엔터프라이즈 시스템에 적용하기에 충분하고 이미 많은 사이트들이 객체지향을 이용하여 구축되었으리라고 생각한다. 이런 기술적인 성숙에도 불구하고 국내에 나와 있는 대부분의 책들은 EJB의 스펙만을 설명하거나 각종 프레임워크에 대한 사용 매뉴얼(user's guide) 수준으로 언급된 내용들뿐이다. 객체지향 기술을 기업의 엔터프라이즈 애플리케이션에 적용하기 위해서는 모델링 기법, 객체와 관계형 데이터베이스의 매핑 기법, 각종 패턴의 활용, 성능과 관련된 문제 등 많은 내용들을 이해해야 한다. 이런 기술적인 성숙에도 불구하고 아직 해결되지 않는 많은 문제들이 있다. 이런 문제를 해결하기 위해서는 개발자 스스로가 다양한 사례와 이론들을 공론화하고 토론해야 하지만 아직까지 국내 객체지향 개발 커뮤니티는 이런 단계까지는 진행하지 못한 것 같다.
이 글의 내용은 객체지향을 이용한 엔터프라이즈 애플리케이션 구축과 관련하여 소스 레벨에서의 구현과 관련된 주제를 다루고 있다. 글을 읽는 독자들에게는 조금 미안하지만 글에서 주장하는 많은 내용들이 틀릴 수 있고 이미 누군가 만들어서 사용하고 있는 것일 수 있다. 하지만 이 글을 통해 여러 개발자들이 토론할 수 있는 기본적인 자료가 되었으면 하는 것이 필자가 글을 쓰기로 결심한 이유임을 이해해 주기 바란다.
필자가 처음 객체지향 기법을 접하고 엔터프라이즈 애플리케이션에 적용하고자 했을 때에는 이것은 풀 수 없는 수수께끼의 연속 같았다. 하나를 해결하면 또 다른 수수께끼가 나타나고, 외국의 웹사이트 또는 여러 참고 서적에 흩어져 있는 조작들을 모으고, 그래도 없는 부분은 직접 만들어서 붙이고 하는 작업의 반복이었다(외국의 많은 사이트의 경우 전체 소스를 공개해 놓은 사이트는 매우 드물었다). 이것은 너무 고통스러운 작업이었으며 프로젝트를 진행하면서 퍼즐을 맞춘다는 것은 거의 불가능의 작업이었다. 약 2년에 걸친 조각 맞춤이 지난 후에야 실제 사용할 수 있을 정도의 모습이 나타났으며 아직까지 이 조작 맞춤은 진행형이라고 할 수 있다.
최근에는 Hibernate, ibatis, TopLink 등과 같이 많은 O-R 매핑 도구가 나타나고 있으며 이들이 주장하는 것은 이제 더 이상 O-R 매핑 도구는 프로젝트 자체에서 만들 필요가 없다고 한다. 물론 이것은 맞는 말이다. 여러 사이트에서 검증된 좋은 도구들이 많은데 굳이 새로운 것을 만들 필요는 없다. 하지만 그러한 도구들을 사용하는 개발자들이 O-R 매핑에 대한 개념을 충분하게 이해하지 못한 상태에서 사용했을 때에는 더욱 심각한 문제를 초래할 수 있다. 이 책에서는 O-R 매핑 도구를 만들어 가면서 왜 이러한 기능들이 필요하며 어떻게 사용해야 하는지에 더 많은 의미를 두고자 한다.
이 글은 현재 자바를 이용하여 엔터프라이즈 애플리케이션을 개발하고 있거나, 이미 개발된 시스템을 유지보수 하고 있는 개발자를 대상으로 하여 작성하였다. 따라서 글의 내용을 이해하기 위해서는 Java 언어의 기초 지식과 J2EE 중 JSP & Servlet, 그리고 JDBC와 같은 기본적인 개념은 이해하고 있어야 한다. 하지만 EJB에 대한 사항은 자세하게 알지 못해도 글의 내용을 이해하는데 어려움은 없을 것이다.
책이 초반부에는 TDD(Test Driven Development) 기법을 적용하여 테스트 코드를 먼저 만들고 실제 코드를 만드는 방식으로 전개하고 있다. 이것은 동일한 기능을 수행하는 코드를 다양한 방식으로 접근해보고, 각각의 장점과 단점을 이해하는 방식으로 진행되기 때문에 변경된 코드의 정상적인 기능 수행여부를 확인하는 방법으로 TestCase를 사용하고 있다. 책의 후반부로 넘어갈수록 필자는 TDD를 사용하지 않는데 이유는 복잡해지는 프로그램에 대한 테스트 코드 작성의 경험부족이다. 테스트 코드에 대한 경험이 없는 내용을 활자화한다는 것에 대한 두려움으로 뒷부분에서는 테스트 코드의 작성을 포기하였다. 하지만 분명하게 강조하고 싶은 것은 이것은 필자의 경험의 부족으로 인한 것이지 결코 자동화된 테스트 코드를 만드는 것이 어려워서가 아니라는 것을 밝혀두고자 한다.
패러다임의 변화
- 도메인 모델(Domain Model)
- 도메인(domain)
- 도메인 모델(domain model)
- object vs. table
- 도메인 모델의 장/단점
- Emp, Dept 도메인 객체
- 도메인 객체를 이용하는 클라이언트
- O-R(Object-Relational) Mapping
도메인 객체 로딩
- 구조적 프로그래밍 vs. 객체지향 프로그래밍
- 연관관계 객체의 로딩(JOIN)
. 도메인 객체의 equals() 메소드
. Mapper(Data Access Object)
. DomainKey 클래스
. DomainObject 클래스
. DBMapper
. 객체는 유일해야 한다
. 트랜잭션
. 트랜잭션 관리와 객체 Pool
. 1:N 관계 로딩
. AssociationLoader
. JOIN 로딩의 문제점
. JOIN 로딩 정리
- 연관관계 객체의 로딩(CASCADE)
- 연관관계 객체의 로딩(Lazy 로딩)
. VirtualList
. 1:1 관계에서의 lazy load
객체 대 테이블 매핑
- 기본 매핑
. 하나의 테이블로 매핑(Single Table)
. FK를 이용한 매핑
- 상속관계매핑
. 모든 클래스를 하나의 테이블(One table for all classes)
. 하나의 클래스에 하나의 테이블(One table for one class)
. 하나의 구체화된 클래스에 하나의 테이블(One table for one concrete class)
- 연관관계매핑
. FK를 이용하여 매핑
. 연관관계 테이블 이용 매핑
게시판 로딩 구현
- 답변형 게시판 설계내용
- 객체-테이블 매핑
- 개발 환경 구성
- 구현을 위한 클래스 다이어그램
- User, Board
- Article, ArticleFile
- 상속 관계의 Mapper
- Article User 관계설정
- Article ArticleFile 관계 설정
- TopArticle Board 관계 설정
- ReplyArticle Article 관계 설정
- 게시글 목록조회
- 게시글 상세조회
객체의 저장
- 객체의 트랜잭션 처리
- 객체의 생성
. 트랜잭션 Pool
- 트랜잭션의 시작/종료/오류
. TxAdapter
. DBMapper의 insert 기능
. TxManager의 트랜잭션 종료 처리
- 객체의 수정
. Dirty flag
. 수정 기능 추가의 편의성
. 1:1 연관관계 수정(Emp Dept)
. 1:N 연관관계 수정(Dept Emp)
. AssociationMapper를 이용한 연관관계 Update 처리
. DomainList
. AssociationList
. 1:N 연관관계에서의 객체 생성(Dept Emp에서 Emp 생성)
. 1:N 연관관계에서의 객체 생성(Dept Emp에서 Dept 생성)
. VirtualList
- 객체의 삭제
- N:N 관계에서의 연관관계 저장
- 양방향 관계에서의 수정/삭제 처리
- 저장소가 DBMS가 아닌 경우 Persistency 계층 구성(SAP/R3)
게시판 적용
- 객체의 로딩
- 게시글 등록
- 게시글 수정
- 게시글 삭제
도메인 모델을 이용한 컴포넌트 개발
- 컴포넌트란?
. 재사용성
. 대체가능성
. 독립기능성
. 구현 관점에서의 컴포넌트
- CBD 방법론
- 컴포넌트 개발
. 컴포넌트 식별
. 컴포넌트 인터페이스 정의
. 컴포넌트 설계
. 애플리케이션 설계
. EJB 컴포넌트
. 컴포넌트 운영 환경(CEE, Component Execution Environment)
. Runtime Object Type Binding
. Deployment Descriptor
. 컴포넌트 구현
. 화면 계층은 컴포넌트 내부인가? 외부인가?
. 컴포넌트에서의 성능문제
. 다른 컴포넌트로 대체
. 컴포넌트의 테스트
. 컴포넌트 패키징
- 컴포넌트 내부 구현
프리젠테이션 계층
- JSP Model2(MVC 패턴)
- Struts
. Struts Model
. Struts View
- JSP Model2 프레임워크 만들기
. FrontController 구현
. Action 구현
. JSP Model2의 문제
- 소스 생성 도구의 사용
컴포넌트 제작 사례
- ACL 관리(Access Control List) 컴포넌트
. 도메인 분석
. 설계
. O-R 매핑
. 구현
. 다른 시스템에 적용하기
. WebServices로 전환하기
Posted by 김형준
- Response
- No Trackback , 4 Comments
Trackback URL : http://www.jaso.co.kr/trackback/35
Comments List
-
와우.. 한권 사봐야겠네요.. 축하..

-
볼 책이 하나 더 늘었습니다....
얼른 보고 싶네요.. -
음..책을 살까말까 고민했는데, 사기로 결심했습니다. 앞으로도 좋은 책많이 쓰시길 바랍니다. 그리고, 세미나 준비도 잘하시고요~






