Search code examples
architecturedomain-driven-designapi-designdistributed-system

Use of DDD Aggregate Services in a distributed architecture?

Suppose I have 2 Bounded Contexts for my university application: Students and Lecturers.

In the backend of my system I have a Student Api and Lecturer Api as distributed applications. Each of these applications interanally adopts the Onion Architecture:

  • Presentation Layer (Http request/response handling)
  • Application Layer
  • Domain Layer (i.e. Student entities/aggregates etc in the case of the Student Api)

Now for the frontend of my platform I use a Client App (i.e. React) which calls out to my Api Gateway. This works great as there exists a Student section of the portal and Lecturer section of the portal, meaning most of the time the pages are backed using the Api results of one Bounded Context or the other.

But there are a few pages of the portal which require data from both Bounded Contexts, for example printing out all the Students on a Lecturer's course.

I could have the Client App send multiple requests which retrieve from both domains and piece the results together, but it would be much preferable if they only had to send one request which returned all the data for the page.

Is it therefore a common implementation to have another distributed 'aggregate' app which sits on top of my domain APIs, to manage (and cache) this orchestration of data? If so what is the name of such an application, because it's essential now another 'higher level' Onion Architecture around my original domain APIs:

  • Presentation Layer (Client App)
  • Application Layer (an aggregate app which orchestrates data from the Student Api and Lecturer Api)
  • Domain Layer (the 2 Bounded Context Apis themselves, which internally implement their own Onion Architecture)
Solution

  • I would suggest in this situation to model a Course aggregate (it might even be its own bounded context; I probably would not necessarily even make Students and Lecturers their own bounded contexts, but that's not really here nor there) with students and lecturer. This aggregate can then, in CQRS fashion, maintain its own view of the information about students and the lecturer (e.g. by subscribing to event streams from the student and lecturer bounded contexts) and only care about the information it needs to care about. Then your client just asks for a course and can get student names.

    One benefit of this is that this query can run even if the services backing other aggregates are unavailable; of course, the price to pay for this is eventual consistency.