Bounded context and sharing business logic (DDD)

Question

We are trying to apply DDD at work, and i'm confused with the way they defined bounded contexts.

They are defining bounded contexts as stakeholders, so in our case we have Customer,Seller, Admin, Sales.

Their argument is, each bounded context has one reason to change (reason as person or a group and thus stakeholders).

The problem is we are duplicating business rules since our bounded contexts are loosely coupled.

So let's say we have a refund use case, Sellers can refund their customers while Admins can refund any customers on behalf of the Seller. The way we defined our bounded contexts, we are now duplicating the refund business rules.

I don't have a better approach of dealing with this, i'm new to DDD, would like to have some help/clarifications on:

• Are bounded contexts supposed to be stakeholders ?
• Is business rules duplication an indication of bad design ?
• How can we model our bounded contexts to better design Admin refund / Seller refund use cases ?

P.S: it's a monolith app

Answer 1

I'm no DDD-guru but I have some experience with it so I'll give it a shot.

A bounded context is just what the name suggests, a context which is bounded, to a specific domain. It has a specific well-defined language and is designed for specific tasks. It often have aggregates of de-normalized state representing use-cases.

A bounded context in your case may be "RefundHandling" or something like that, with aggregates for perhaps "SellerRefundProcess", and entities or just values for "Seller" etc depending on each use-case.

Bounded contexts should be loosely coupled as you write. That's a big reason for dividing a complex domains into more specific domains focusing on specific tasks/use-cases. But if you have business rules you have to share between these domains, then yes perhaps they are not so different after all. Perhaps your domain could be divided in other ways, if any.

An easier approach would be to share the common rules you have with shared kernel assembly. Not as clean but sometimes it's unavoidable.

Just some thoughts and ideas, for what it's worth.