14

We are developing a system which is composed of multiple bounded contexts, there are user interfaces where the information displayed needs to be rendered from multiple bounded contexts.

A classic example of such an interface is the Amazon.com ordering page. Where we see about the product (product BC), inventory available (Inventory BC), prices and so on.

My question: in such scenarios, in which bounded context would the user interface live? I get how we can pull data from multiple BC's to form the page, but are there any guidelines as to where the page itself should reside?

Similar questions here and here, they deal with how to get information from the multiple BC's, but they do not address in which BC the user interface itself will live in ?

Any guidelines on that question With an example would be great...

Community
  • 1
  • 1
Sudarshan
  • 8,574
  • 11
  • 52
  • 74
  • how did you organize the source code in the end? Did you have one web app for all bounded contexts or one web app per bounced context? If the latter, then did you use mvc areas? +1. – w0051977 Jan 15 '18 at 01:31

2 Answers2

11

I'm no expert, but I believe the UI does not live in a BC. The UI is an expression of one or more BCs. The BC is a boundary around decisions that are linked. How you surface that to the user is not it's concern.

So for instance you have a web page, such as amazon.com with several BCs as you say, the UI merely guides you along helping you make decisions in whichever BC your are involved with.

One last attempt. If you envision a diagram of either a hexagonal architecture or a layered architecture, you would have at the very outside (top) a UI of some sort. It would communicate with an anti-corruption layer (or application service). This A-C would then delegate to the proper BC to handle the command you wanted fulfilled.

Ruben Bartelink
  • 59,778
  • 26
  • 187
  • 249
Raif
  • 8,641
  • 13
  • 45
  • 56
  • Yes, this is a new line of thought for me :), well if we said that each BC was a repository in Github or any VCS, then where would the user interface code physically lie ? – Sudarshan Sep 30 '14 at 00:48
  • well, first I would advise against over segregation or premature distribution. If your system needs that then great, but if not then you are adding complexity for no reason, you add those features as the need arises. Second, I use .net, you could have a repo that only contains your web app and maintains a connection to the BCs through messages or direct dll refs, or if you have all the projects in one repo you can include the projects that you need in your web app. – Raif Sep 30 '14 at 16:47
  • Did think about this, however this would mean that all the views reside within the webapp and repo's referring to each of these BC's would not have any UI representation (views). I would like these BC's to be offered as independent software's as well and hence want the views related to each of the BC's reside in the BC repo itself – Sudarshan Oct 01 '14 at 05:19
  • pretty hung over this morning but let me take a stab. Again, a BC doesn't have a UI, you may have one or more UI's or consumers of a BC though. You may have one for your clients and one for your admins, both different websites, but interacting with same BC. So if your BC encompasses enough domain that it can serve a UI, you can add a website to that repo, and have an uber website that interacts with several BCs. The BC doesn't have a representation other than the domain model. You can create read views anywhere that can listen to your events. – Raif Oct 01 '14 at 13:56
  • This Makes a lot of sense, the uber site would need all the other bc's to be live for it to work, how about duplicating the data in a read store which the uber website refers to, just so that the uber website can function even if one of the bc's is not up, the read store is updated via events, does this approach make sense ? – Sudarshan Oct 02 '14 at 07:53
  • yes, that does make sense, sort of, your BCs should just handle your coammands, the writes, and the events. You should have handlers that listen to those events and write to your read store. If your BC is in a service and it goes down, depending on how you contact it, you could be SOL. If you are using messages to contact your BC then you will be able to write when the BC comes back up. But basically when a service goes down you are out of business till it's back up. – Raif Oct 02 '14 at 13:43
  • two things, a) why don't you check me as the correct answer? that gives me points or something. I think I can trade them in for free fries at burger king. b) you should look for me on jabbr.net ddd-cqrs-es. it's really a much easier medium to connect on, and you can watch me flail hopelessly as I learn to do domain modeling. – Raif Oct 02 '14 at 13:45
  • I would be glad to mark it as accepted once we can consolidate our discussion into your answer, I think we are concluding that at a high level there are 2 ways that the uber website can show information from across multiple BC's. 1) via synchronous calls, this would mean that all the BC's need to alive for the uber site to work 2) via messages where the BC's update the uber website read store, this means that if one of the BC's are temporarily down the uber website would still function. The UI lives outside of any BC. – Sudarshan Oct 02 '14 at 14:26
  • well, I think in both cases you would be writing to your read stores, and those read stores would be independent of the BCs, that is any BC can access them. What we are talking about is cqrs, so your BCs are for writing, and your read store is for your reads. if one of you BCs is down you will be able to read fine, just not write, which sounds unfine. Further, I would imagine that the read stores are used by all web apps. – Raif Oct 02 '14 at 18:32
5

The user interface has its own concerns and collaboration patterns; it is a BC in its own right.

Bryan Watts
  • 44,911
  • 16
  • 83
  • 88
  • 1
    A BC is more of a conceptual level DDD term, I have probably used it in the wrong context ... I am trying to figure out how to divide the source code based on BC's ... I think in many cases having a repo per BC is a fair deal. From there I am trying to figure where UI's which compose information from multiple BC's should lie ... – Sudarshan Oct 02 '14 at 17:37