When to split bounded contexts?

[Dominik Hufnagel]

HI,

I want to learn about DDD and I am having some problems of understanding where to put boundaries.

Let's say I have a kind of Groupware with calendar, contacts, mail and documents. The contacts have a history with mails, appointments and documents.

Now is this a single bounded context for the whole groupware? Or do I have multiple bounded contexts for contacts, calendar, mail and documents? 

Is this a good example of using DDD? Or should I stick with the classic CRUD as there may not be much domain logic?

Thanks

Dominik

[Rafał Krasowski]

Hello.

First of all, its hard to tell that you should or shouldn't use DDD. It depends and you need to figure it out by yourself.
To help answer that question, you need think about your business logic.Does it contains a lot logic? For example,
If you schedule an appointment what should happened?
Send mail to participant.
Does someone need to approve an appointment?
Does someone could reject it ?
Maybe he can send an request for new date, because he is busy it that time.
Maybe after an appointment are approved by all participants, new document "MeetingNotes", are created in local intranet.

All of this is kind of domain policy. You can replace it with any new policy, and core application is intact.
One of benefits making DDD is that you could easy unit test some logic in your application.
Definitely, you want to test policy.

If you haven't complicated domain, it's probably better to stick with CRUD. Trust me, hours of development saved. In all you need to have working product.

I recommended to read some articles, there are plenty of them in web.
https://martinfowler.com/bliki/BoundedContext.html
Defining bounded context is one of hardest question in DDD, so answer could not come so easy.

Hope, i help you.
Best regards, Rafał.

[Dominik Hufnagel]

Hi Rafal,

thanks for your answer.

I am thinking a lot about DDD and software design at all in the last few days. I get the concepts of DDD but do not really like all of them. For example the data duplication of BCs by using different databases. Or even worse the eventual consistency. I want my data to be consistent! I may understand using such practices in very large systems, but in our application we have no need for it.

But I do want to use some concepts of DDD, or rather of OOD. In the example above, I have a input form for creating an appointment and the same for editing it. So I think doing this with CRUD is a good choice. But on the other hand I also like my domain model to be expressive. I like the idea of having a "reschedule(DateTime)" method to change the date and time of the appointment and get rid of the setters of the object. But if I do so, what will I call if I change the appointment using my form? Do I have to check which data changed in the UI and call the appropriate mehtod?

Best regards

Dominik

[Rafał Krasowski]

I still learn DDD, and its hard.

Its good to start with some side project and create prototype, develop practices, through that process
you will learn a lot, and probably you will able to tell when to use or when to not.

You could adapt your design, but you need to know what you could and what not, it comes with practice.

Look on outlook and office 365, it contains everything you listed is in this post (calendar, contacts, mail and documents),
and everything handle separately, but UI is composition of all features.
TIP: How small micro service should be? Ideally 1 Micro service should contain 1 BC.
Maybe that's the way you could imagine your boundaries, and communication between them.

DDD is oriented around aggregate concept, and its crucial to apply. It means, you want to load aggregate graph instead of single/multiple entities.
Going further, when you define your aggregates then your BC will reveal itself, if you does it wrong, you should noticed it in design.

Making Reschedule(DateTime) introduce encapsulation, with in my opinion could be used even in CRUD,
you just get rid of setters, and change them into methods. Its a clear and straight forward path do CQRS.

Talking about code, basicly it looks like:
From UI you could request ResheaduleCommand(DateTime:newDate, bool:notifyOthers) to your controller action, and pass along to command bus.
Then Command Handler load an aggregate (via Repository), validate, and call
_unitOfWork.Repository<Appointment>().Rescheadule(:newDate, resheadulePolicy).Save() - this triggers aggregate logic
if(nofityOthers){ _notifyService.Notify(appointment.Recipients)}

You change one Update() => to many Scheadule/Rescheadule/Notify/ChangeAgenda Commands

It is some work need to be done.

Best Regards
Rafał

[Ramin]

Hi Dominik,

DDD is not eventual consistent per se, neither is CQRS. The write and read models can use the same data store. Event sourcing can be used to implement CQRS, which then makes it eventually consistent. But even here you "can" build a consistent read model.

Bounded contexts are about language. If the language/ terms to express business objects are different between contexts, having separate data stores should make more sense.

Hope this helps, cheers
Ramin

[Dominik Hufnagel]

Hi Ramin,

thanks for your answer.

I know that you could have consistency in DDD applications. And I am familiar with the event store thing.

But thinking of my example, I have a hunch that this would be a single bounded context. I cannot think of different stakeholders having different meanings for a contact in term of contactmanagement, or an appointment in term of calendar management. I rather think that it would make sense to seperate these things in modules, which also could be reused. So is having modules contrary to DDD or can/should both be used together?

What if I have an "end user" application, lets say a electrician which uses these groupware features, but there is also a feature on top of the groupware to allow the electrician to create invoices. Would bounded contexts make sense if the application is just for one specific stakeholder? Or would that simply be one BC?

I find it hard to tell if BCs should be created on module boundaries or on "stakeholder boundaries" or even other boundaries..

Kind regards

Dominik

[jageall]

A bounded context is just a boundary around domain terms with the same meaning. You only have separate bc when you have 2 domain terms with different m meanings, although spotting this can be hard sometimes. A bc can contain as many modules and (micro)services as makes sense in your domain.

[Ramin]

Hi Dominik,

like jageall mentions, it can be hard to spot different domain terms with different meanings sometimes. I am still a novice in modelling, so cannot really give you much advice. But basically everything inside one BC should be consistent, and that includes the language and terms being used in order for all the stakeholders (domain experts, programmers, etc.) to be on the same page. Modules can fit nicely into one BC and do not necessarily represent natural boundaries for BCs.

I wouldn't go ahead and try to split everything into different BCs from the start, unless the boundaries are obvious. Start modelling the domain, and then see where the same terms pop up and have different meanings. But maybe others can jump in here for more and better advice.

Cheers

Ramin

[Ramin]

Hi Dominik,

you also mentioned not liking aspects such as data duplication of BCs by using different databases. Not sure if shared kernel is what you would be looking for here.

Cheers

Ramin