DDD bounded contexts, shared tables

Question

We're in the middle of writing a new app from scratch and planning to use DDD for this but we're all new to the process and trying to figure things out. The app at its core is a video conferencing tool, but within that we've got a number of subdomains that we're looking at make bounded contexts

• Meetings - managing the meetings themselves
• Calendar - integration with calendars
• Transcripts - processing transcripts from the calls

Probably some others, but these pieces feel like they're logically separate. The issue I'm now unsure about, is the database. We've got a single database for the application, but each of the bounded contexts will need to access data from the same tables.

For instance, the calendar integration will need to make changes to meeting records to reflect changes in the calendar. Transcripts will update the meeting to attach the links for the resulting files.

Obviously we could create an entity in each context to represent these, but underneath it's still the same database table.

Is this a problem? Or is it possible the app isn't even big enough to warrant bounded contexts at all?

Answer 1

DDD Bounded Contexts has always been a somewhat vague idea. You can see that when you are speaking to "the business" about Domain Terms and the Domain Language you might get different parts of the business using different terms for the same thing, or the same term for different things. Thus you need some sort of context to keep them seperate whilst also using the Domain Language in your software.

How this translates to actual code though can be problematic.

My gut reaction to your description of the problem is that you don't have any Bounded Contexts or Bounded Context problems at all, just three separate products which will naturally have APIs they use to integrate with each other. Let's look at your example case:

For instance, the calendar integration will need to make changes to meeting records to reflect changes in the calendar

Rather than make changes to the table directly, I would have the the Calendar app make an API call to the Meeting app. "Meeting Date Moved"

That way the Calendar app doesn't need to know about any Meeting objects outside of the integration method signature.

Alternatively you could have an underlying EventsApi handling all sorts of events which both the Meeting and Calendar apps call for data.

In this case both apps might have their own Event objects populated from the underlying EventApi. the objects would have different methods and perhaps extra data added to them from other sources.

You would now need to talk about Bounded Contexts, because the word "Event" now has three meanings. But you still don't have any issues with database tables, because only the EventApi knows about the events table.