微服务DDD CQRS

Question

I've been reading about DDD and microservices. Started to prototype by taking a use case for CQRS part. The use case is a sports soccer app which has videos, news, scores, and homepage. In this, I've identified the domains and Bounded context which are

1. News

2. Videos

3. Scores

4. Homepage

First, 3 domains are totally independent of each other.

Now, homepage domain requirements. 1. Score section 2. Videos section 3. Content section

Content Section: It has its own database

Videos section: It will make HTTP call video service and get the data

Score section: It will make HTTP call Score service and get the data

My question is with homepage domain. I find it is highly coupled with other services and it's not independent.

How can I design homepage domain?

Answer 1

I find it is highly coupled with other services and it's not independent.

Yes.

You can improve the independence by thinking carefully about the failure modes; how should the UI elements behave when the relevant data authority is not available. You can, for example, have the homepage simply display a "data not available" message if the remote authority doesn't respond in a timely fashion. Or you can have the homepage display a cached copy of some stale data. It may even make sense to always render the response using cached data, with updates to the cache happening in the background.

There are techniques that you can use to reduce the coupling between the services.
One approach is described by Udi Dahan, under the umbrella of UI Composition Techniques . His idea is that you use an element, like a widget , to encapsulate the logic of display and the failure mode.

The underlying mechanics aren't really all that different; the widget has all of the same problems we had before when the data isn't available. But what it does do is separate out two problems (what do you do when the widget isn't available, what do you do when the data isn't available) that belong to different teams: the homepage team gets to decide what to do when the widget isn't available (perhaps a cached copy is used), the service team gets to decide what to do when the widget can't reach the backing data (perhaps the widget has its own cache of stale data).

There's no magic; you've got a distributed system, and a consequence of this is that you need to consider in your design the fact that the remote processes won't always be available.