tag:blogger.com,1999:blog-4338956765494283322.post7476437259161209861..comments2024-02-21T03:15:53.416+08:00Comments on Bill Poole's Creative Abrasion: Consumer Driven ContractsBillhttp://www.blogger.com/profile/12877394913101625095noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-4338956765494283322.post-16747971610245824412023-10-01T03:13:26.248+08:002023-10-01T03:13:26.248+08:00Interestingg readInterestingg readFlorida Blockchain Business Associationhttps://medium.com/@Jmdsanoreply@blogger.comtag:blogger.com,1999:blog-4338956765494283322.post-85042651655731525782020-06-10T16:32:46.913+08:002020-06-10T16:32:46.913+08:00Nice blog and absolutely outstanding. You can do s...Nice blog and absolutely outstanding. You can do something much better but i still say this perfect.Keep trying for the best. Please search <a href="https://www.desksta.com/" title="instagram viewer" rel="nofollow">instagram viewer</a> to discover nice photos and videos on instagram. Sophie Gracehttps://www.blogger.com/profile/09769321133171248409noreply@blogger.comtag:blogger.com,1999:blog-4338956765494283322.post-81977686612013529812008-08-12T12:20:00.000+08:002008-08-12T12:20:00.000+08:00Hi Ian,Thanks for your comments. Indeed business ...Hi Ian,<BR/><BR/>Thanks for your comments. Indeed business services will participate in several different enterprise processes.<BR/><BR/>The granularity of your business services will however determine the number of complexity of business processes in which each business service participates.<BR/><BR/>If business services are very coarse grained, aligning with high level business functions (cohesive process areas), then each business service will participate in comparatively fewer business processes. These business processes will be very high level broadly scoped (end-to-end) processes.<BR/><BR/>If business services are very fine grained, then each service will participate in orders of magnitude more business processes, the needs of which will all need to be accounted for and managed.<BR/><BR/>To that end, I would suggest that consumer driven contracts are of limited use if the business service granularity is appropriate.<BR/><BR/>To use your product example, a product should have single representation within a given business service, but different structure and semantics across different services.<BR/><BR/>The publishing service expresses its events with the structure and semantics appropriate for itself. Other services then <I>map</I> this representation to their own representations when notification messages are received.<BR/><BR/>With regards to deciding which events to publish, I tend to publish <I>all</I> relevant business events, regardless of whether there are any existing interested subscribers.<BR/><BR/>With SOA, the ideal unit of reuse is the <I>event</I> rather than the <I>function</I> (which you can read more about <A HREF="http://bill-poole.blogspot.com/2008/04/soa-and-reuse.html" REL="nofollow">here</A>).<BR/><BR/>If you aren't publishing all business relevant events, then when it comes time to implement a new business process within a service component one would need to go back to the service where the event occurs and modify it in order to publish the event.<BR/><BR/>The business architecture should determine which events will be published. Business events are used within the business architecture description to coordinate the execution of business processes (see <A HREF="http://en.wikipedia.org/wiki/Event-driven_process_chain" REL="nofollow">Event Driven Process Chains</A>).<BR/><BR/>Cheers,<BR/>BillBillhttps://www.blogger.com/profile/12877394913101625095noreply@blogger.comtag:blogger.com,1999:blog-4338956765494283322.post-77088783947731474432008-08-09T04:56:00.000+08:002008-08-09T04:56:00.000+08:00Hi BillSome really excellent points here. I agree ...Hi Bill<BR/><BR/>Some really excellent points here. I agree that consumer expectations of a data-centric service can vary wildly from consumer to consumer; whereas business-meaningful capabilities hosted in business services aligned along organizational lines tend to be consumed in a more homogeneous fashion. Understanding this difference helps determine when to push for full-blown consumer-driven contracts, and when to downplay their significance.<BR/><BR/>Having said that, my thinking around <A HREF="http://www.infoq.com/articles/consumer-driven-contracts" REL="nofollow">consumer-driven contracts</A> has evolved in tandem with my preference for hosting business capabilities in services aligned around organizational units and business-meaningful processes, and for using publish-subscribe, event-driven interactions. Go figure! <BR/><BR/>Business services often end up being threaded in several different enterprise processes, with slightly different usage patterns and consumer expectations, and to that extent consumer-driven contracts help describe the aggregate usage context on behalf of a provider. To a degree, consumer contracts serve as an antidote to enterprise canonical schemas: product, for example, has different semantics in different, yet specific usage contexts. The only things of real importance are these specific instances of usage, which show what really needs to be provided, in this context or that, in order to realize this outcome or that, rather than some perfectly normalized Platonic schema. <BR/><BR/>With regard to events and notifications, I’ve used a very lightweight consumer-driven approach, in the form of “stories for services,” to help discover which events a service ought to publish: if nobody’s interested, don’t waste your time publishing to the void.<BR/><BR/>Anyway, great blog – I only came across it today after going over some of Udi’s old posts. Glad I’ve found it.<BR/><BR/>All the best<BR/><BR/>ianIan Robinsonhttps://www.blogger.com/profile/10603823336169432222noreply@blogger.com