One UI talking to many Bounded Contexts

[Andrew Easter]

It seems to be a pretty realistic scenario that a single logical UI (say a public facing website) would integrate in some way with more than one Bounded Context. For example, an e-commerce site may have separate bounded contexts for product catalog and inventory/stock control, yet their public facing website would most likely present a product alongside whether it's "in stock" or "sold out".

The crux of my question is, what Bounded Context would the UI application fall under? Assuming CQRS is in use, hopefully I'm not mistaken that read models/views, and apps/services reading from them, also exist with a Bounded Context? So, in this example, would such a UI application and/or associated read model/views exist in their own separate context altogether, or do they belong to the the core product catalog domain context whilst simply listening into events being published from the inventory/stock control context?

[Raimondas Tijūnaitis]

Hi, 

I think you are talking about composite UI application. This is completely normal and natural scenario.

There are some pretty good slides on this (75 slide amazon example) - http://www.slideshare.net/jeppec/cqrs-why-what-how#btnNext

Also Vaughn Vernon IDDD book has also some clarifications how to define BC in this kind of scenarios.

Raimondas. 

[Andrew Easter]

Thanks for this. I'm already in the middle of Vaughan's book but, to be honest, still struggled to fully grasp the answer to my original question - that's why I asked on this mailing list.

I've looked at the slides - the composite application crosses the three BCs. But, where does it "live"? Is it in a separate BC? Does a different team look after it?

It's these questions that cause me a great deal of confusion!

[Andrew Easter]

Thinking more about this, another factor which I think is clouding my view is the mix between agile and DDD. 

An agile User Story is encouraged to focus on a feature from the perspective of a user. In the ideal scenario, a single team could work on that feature end-to-end. However, in the existence of multiple Bounded Contexts (which would ideally be each owned by a different team), it does not seem at all practical for just a single team to work on a feature that cuts across multiple Bounded Contexts. If you consider a Composite UI, it may be that a team working on that will have dependencies on teams owning the multiple Bounded Contexts for which a feature depends on. In this case, it's not possible for the Composite UI team to deliver a story/feature end-to-end.

I suppose, though, that this is less an issue with DDD, more just a general issue in believing it's possible, in a large system, to realistically have one team deliver a feature end-to-end? 

Of course, user stories can be broken down to be more specific/granular, but then aren't you moving away from the intention of the user stories - in breaking them down, don't they inevitably become more technically oriented as opposed to user focused?

[Kijana Woodard]

Pull requests ftw.

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Ben Kloosterman]

These bounded contexts can also server diffirent UIs / apps. .

Ask the same questions for a UI using 3 SOA services . They can live anywhere or be owned by any team as need be. 

Ben

[Andrew Easter]

On Saturday, 23 November 2013 17:40:23 UTC-8, Bennie Kloosteman wrote:

These bounded contexts can also server diffirent UIs / apps. .

Ask the same questions for a UI using 3 SOA services . They can live anywhere or be owned by any team as need be. 

So, you're saying a composite UI can just "live anywhere" and not within a specific bounded context? I could still imagine a composite UI maintaining its own views that form projections of data from multiple bounded contexts - does this make the UI a bounded context in its own right, one that integrates (probably via event subscription) with many other bounded contexts?

I apologise if my questions sound dumb, but coming from a non-DDD enabled, agile background, some of these concepts are harder to fit together into a cohesive picture than one might think.

[Ben Kloosterman]

They are not dumb questions but dont directly relate to CQRS , they are architecture questions and as has been stated by many CQRS is not a top level architecture.  Your architecture will determine the answer. 

Whether you wrap an existing bounded context in a new one or call it direct is completely up to you  in some cases its good , in others not.

That said its always worth remembering the first rule of distributed systems. 

Ben

--

[Dinkar]

Andrew,

My experience has been that having the "so-called" front facing apps in their own BC is not a bad idea, especially when its of composite solution type. In such cases, the composite UI (portal) is essentially being assembled in a composite setup and the UI fragments (portlets/widgets/gadgets/iframes :)) are all rendering UI which is being delivered by individual providers. Each of these providers can very well be within their own BC (should be). Example - an online banking portal is a composite app built on providers such as payments, accounts, trading, research etc.. each of which resides in its own BC and offers the UI to be used in the portal composition.

Hope this helps. Happy to learn more too

[Dinkar]

Forgot one thing. Generally the composite solution is owned by a separate org unit not necessarily the individual areas (payments etc..) and in that case also it makes sense to have the Portal being managed as a separate BC

[@yreynhout]

Sometimes a UI is its own BC, yes.

[Andrew Easter]

Lots of useful answers. Thanks everyone.

Andrew