비즈니스 컴포넌트와 데이터 ownership

비즈니스 컴포넌트의 내부 구조는 레이어드 방식보다는 크로스 레이어드 방식을 선호한다. 그러한 성질로 인해서 컴포넌트 간의 의존관계는 상당히 중요한 정보로써 관리되어야 하며, 이는 컴포넌트 방식으로 중요 비즈니스 로직을 구성할 경우, 지속적으로 모니터링이 되어 해당 컴포넌트 간의 의존관계가 비즈니스적인 의미가 있게 구성되어야 한다.

따라서, 이를 위해서는 당연히 데이터에 대한 ownership 문제가 제기되지 않을 수 없으니, 논리적인 데이터 모델 뿐만 아니라, 물리적으로 무결성을 위해서 테이블 간에 많은 FK를 통해 연결된 데이터베이스 구조의 성격상 ownership을 나누기는 여간 불편한게 아닐게다. 컴포넌트의 의존관계를 관리할 수 있는 수준이라면, 당연히 데이터의 ownership을 지정하여 관리하도록 구성하는 것이 비즈니스 컴포넌트의 성격을 규정하는데 더 낫다. 예를 들어, 고객(Customer)라는 엔티티 컴포넌트가 주문(Order)이나 배송(Delivery)과 같은 개념의 데이터를 가지고 있다는 것이 논리적으로 컴포넌트의 무결성을 유지시키지 못하기 때문이다. 하지만, 컴포넌트와 데이터와의 연결을 하는 순간 이러한 규칙을 지킨다는 것이 어렵다는 생각이 들 것이다.

다음은 Business Component Factory에 있는 "island of data" 개념에 대한 내용이다. 이를 보면, 데이터에 대한 ownership을 비즈니스적인 의미를 부여하여 구획하는 것이 중요하다는 것을 알 수 있다.

데이터베이스 컴포넌트화 (Database Componentization)
DB 모델링과 이에 대한 구현은 전사 CBD에서 중요한 역할을 한다. 많은 CBD 전문가들은 주어진 비즈니스 영역의 컴포넌트화가 아래 그림과 같은 상황에 도달했을 때 완료되었다고 생각하고 있다. 즉, 비즈니스 로직은 컴포넌트화가 되었지만 하나의 단일 통합 DB를 통해서 이를 수행하게 된다. 모든 컴포넌트들은 비교적 제약되지 않은 상태로 모든 데이터베이스 테이블에 접근할 수 있다. 객체지향 관점을 가진 CBD로 접근하는 많은 사람들이 아래와 같은 사상으로 DB를 적용하고 있으며, 따라서 통합 DB (integrated database) 스타일라고 할 수 있는 아키텍처 스타일을 준수하게 된다. 물론, 통상 DB는 적절한 데이터 아키텍처를 준수해야 할 것이며, 특정 방법이나 기타 다른 방법으로 모듈화가 될 것이다. 하지만 이러한 모듈화는 기능적인 논리 컴포넌트화와는 별도로 수행되며, 데이터 관리 아키텍처는 컴포넌트 아키텍처와는 독립적이라고 할 수 있다.
통합 DB 스타일은 아키텍처가 프로세싱과 데이터 관리 관점으로 분리된 대규모 시스템에 전통적인 방식이다. 이러한 접근 방법의 문제는 독자적이어야(autonomous) 한다는 컴포넌트의 기능을 심각하게 해친다는 것이다. DB는 통합이 되는 지점이며 컴포넌트 간의 수많은 의존관계를 만들어낸다.
진정한 컴포넌트 독자성(autonomy)를 보장하려면, 해당 컴포넌트와 직접적으로 관련된 모든 것들이 컴포넌트 그자체의 부분이 되어야 한다. 이는 컴포넌트 입도가 분산 컴포넌트인 경우에 거의 불가능하다. 예를 들어, 전사 분산 컴포넌트에 사용자 인터페이스를 포함하는 것은 의미가 없으며, 개별 분산 컴포넌트에 저장 영역을 포함하는 것이 적합하지 않다고 경험이 말해주고 있다. 하지만 이러한 포함은 비즈니스 컴포넌트와 시스템 수주느이 컴포넌트에서 완전하게 수용가능하다.

DB는 마찬가지로 적절하게 컴포넌트화가 되어야 하며, 저장 데이터는 개별 비즈니스 컴포넌트에 적합하게 할당되어야 한다. 이는 분명 논쟁의 여지가 있지만 비즈니스 컴포넌트의 독자적인 개발을 지원하는 강력한 설계 원칙이며, 컴포넌트화된 DB(componentized database) 스타일이라고 한다. 이 스타일에서 개별 비즈니스 컴포넌트는 "데이터의 섬(island of data)"을 포함하며, 이러한 그림이 아래 나타나있다. 이러한 상태를 island of data 원칙이라고 한다.
데이터의 섬은 완전하게 비즈니스 컴포넌트 내에 포함되며 설계시 테이블 정의가 되며 - 컴포넌트 특화된 스키마와 대응되는 - 실행시에 관련 데이터가 된다. 비즈니스 컴포넌트 그 자체의 외부에 있는 어떠한 저장 데이터와도 직접적인 연결이 없기 때문에 island라고 한다. 데이터의 섬에 있는 테이블은 (컴포넌트에게)local 테이블처럼 사용될 수 있다. 레이어드 아키텍처에서 각각의 데이터의 섬은 관련된 리소스 티어를 가지며, 리소스 분산 컴포넌트로 구현될 수 있다.

분산 티어는 동일한 비즈니스 컴포넌트에 속하는 엔터프라이즈 티어에서만 접근 가능하다. 비즈니스 컴포넌트는 엔터프라이즈 티어에 하나 이상의 분산 컴포넌트를 가질 수 있기 때문에, 아래 그림과 같이 해당 리소스 티어 인터페이스에 대해 동일한 접근 권한과 가시성을 가진다.

island of data 원칙을 적용하기 위해서 전체 DB는 섬들의 집합으로 쪼개져야 하며, 이는 비즈니스 컴포넌트가 소유하게 된다. 비즈니스 컴포넌트 내에서 정규화, 쿼리 최적화, 참조 무결성과 같은 모든 일반적인 관계형 원칙과 기법이 기존과 같이 적용된다. 단지 차이는 해당 섬의 외부에서 데이터를 접근하는 유일한 방법이 SQL 인터페이스나 직접적인 접근 메커니즘을 통하는 것이 아니라 비즈니스 컴포넌트의 인터페이스를 통해서만 가능하다는 것이다.
개별 비즈니스 컴포넌트는 자신의 저장에 대해 관리를 한다. 비즈니스 컴포넌트 사용자는 인터페이스 뒤에 RDBMS가 있는지, 파일 시스템이 있는지, 메모리 저장을 사용하는지, 혹은 인터페이스를 통해 넘어오는 모든 데이터가 인터넷과 같은 다른 경로를 통해 얻는지에 대해서 알지 못한다. (알 필요가 없다.) 위의 island of data의 그림은 저장에 대한 논리적인 관점을 나타내며, 이는 새발시 혹은 배포시의 관점을 의미한다. 논리적으로 DB가 여러 컴포넌트에 쪼개져서 보인다는 사실이 실행시에 물리적으로 서로 다른 DB에서 실행되어야 한다는 의미가 아니다. DB 기술의 현재 한계에서 대부분의 경우 실행시에 아래 그림과 같이 구현될 수 있다. 모든 데이터의 섬들은 물리적으로 동일 DBMS와 리소스 매니저에 위치하게 된다.

데이터의 섬으로써 저장 모델의 뷰는 시스템의 "트랜잭션 부분"을 강조하는데 적절하다. 즉, ERD이다. 레포트 작성기와 같은 DB 관련 도구에 의해 제공되는 컴포넌트 지원에 대한 현재 수준에 따라 DB를 전체적으로 볼 수 있는 특정 도구를 필요로 할 수 있다. 이는 DB와 컴포넌트 기술의 성숙도와 같이 변경될 수 있지만, 어느 쪽이든 island of data 개념의 강점은 영향받지 않는다.
DB를 island of data 관점으로 생각함으로써 문제 영역의 컴포넌트화를 더 발전된 단계로 옮길 수 있다. 기능 로직과 사용자 인터페이스 컴포넌트화의 비즈니스 컴포넌트 할당 뿐만 아니라, DB 모델링에 대한 부분까지 컴포넌트 할당이 될 수 있다. 이는 몇가지 새로운 개념과 원칙을 필요로 한다.

이상과 같이 비즈니스 컴포넌트 개념은 데이터 관점에서도 마찬가지로 비즈니스 클러스터링이 되게끔 구성되어야 함을 의미한다. 이것이 컴포넌트와 DB 간에 풀어야할 숙제이기도 하다.