데이터 모델과 데이터 발생 프로세스 사이에서의 고충

최근에 계속 고민하고 있던 문제의 실마리를 찾아나섰다가

한 부분 "고충" 과 맞물린 부분이 있어서, 스스로 정리겸 리마인드겸 올려둡니다. 

렌 실버스톤 아저씨의 vol.1 책 내용입니다. 

기본 모델 구조는 

[PARTY] --------<- [ PARTY ROLES] ->-------- [ROLE TYPE]

위와  같이 어디선가 보았음직한 형태일 겁니다. 

Should Roles Be Defined at the Time of the Transaction?

One may make the point that the enterprise doesn't really know the role of the party until certain transactions take place and therefore this role information is derived and unneeded. 

For instance, if CUSTOMER is defined as a party that has purchased, been shipped, or used products, the ORDER, INVOICE, DEPLOYMENT USAGE (from Volume 2) or SHIPMENT entities will dictate who is a customer;

this information will be available from relationships between these entities and the PARTY entity.

As a practical matter, it is important to be able to declaratively state that "XYZ company" is a prospect, although there aren't any transactions that the enterprise maintains about the event of becoming a prospect.

Similiarly, the enterprise may want to declaratively state a certain party is a customer even though there aren't any associated transaction. Additionaly, even though this is a technical consideration, the enterprise , as a practical matter, would want to know who was a customer, supplier, employee, and so on without having to search for the related transactions.

The relationship-independent roles such as "notary" and "doctor" need to be declaratively stated without necessarily being related to transactions that the enterprise is interested in storing.

Another point about the argument of these roles being defined when the transactions occur is that, in some circumstances, the enterprise could instantiate these roles at the time of the transactions. 

The roles do not necessarily have to be instantiated before any transactions occur. 

For instance, when a party places an order, the party could then be set up as an instance of a PARTY ROLE of a CUSTOMER (and the enterprise may specifically have them in several customer roles such as BILL TO CUSTOMER, SHIP TO CUSTOMER, END USER CUSTOMER) and then the ORDER could be related to these instances.

외부연계에서 예상치 못한(어떤때는 오류이더라도) 데이터가 발생해도 우선은(사실 무조건적으로) 수용을 해야 할 때가 더러 있지요.

데이터모델 그리고 현실에서 데이터를 송수신하는 상황 사이에서 발생하는 고충중에 하나일 수 있겠네요 

관리할 수 없는 정보이거나, 트랜잭션이 발생때마다 확인하고 생성해서 만들어 줘야 하는 상황이 발생하는데요

특정 역할을 최초로 수행할 때에 등록을 해주고, 이 후에 새로운 역할이 발생시 기존에 없으므로 새로이 '역할' 을 instantiate 해주어야 하는 상황인데요. 개발자들 입장에서는 이렇게 되면 모든 트랜잭션의 '역할' 에 해당하는 무언가가 존재하는지를 확인하는 프로세스가 빠짐없이 들어가 줘야할 텐데라고 생각하는 순간 머리가 한 짐 또 무거워집니다. 

단순화한 예를 들자면, 일반적으로 회원가입을 하고 나서 구매결제를 하는 프로세스가 정상이겠지만

구매결제를 하기 위한 정보를 가지고 회원이라는 정보를 만들어 주어야 하는 경우가 있습니다. 

(허용되어 있는 한에는 정상 프로세스라고 간주하고 설계를 할 수 밖에 없지 않을까 싶네요)

설계사상과 같이 물 흐르듯이 데이터가 흘렀으면 하는 바람이나,,, 현실은 프로세스가 꼬여있든 무언가가 꼬여있든 모델러의 고민과 사색(?)의 시간을 늘여줄 요소들이 참 많은 것 같습니다.