5

I am considering how to set precise boundaries of bounded contexts. Considering that a bounded context is a solution space, sometimes it is very difficult to set what exactly is your solution space.

Here is an example. I have following bounded contexts

  • Ordering
  • Messaging
  • Content management
  • Warehouse etc.

So in a real life situation this is a possible situation

  • Ordering needs to send a notification
  • Ordering gets a message draft from Content management
  • Ordering formats a message and forwards it to Messaging
  • Messaging send a notification and does all the work relevant for that BC (send message, archives it, logs it etc)

This looks like a valid design, but I have some doubts regarding it. For example, should Messaging be also part of an Ordering "solution space" and also maybe Warehouse "solution space" (not as BC of-course, just as code). In that case design of Messaging could change for each "solution space" according to its needs (if any).

By pulling it out from multiple BCs I wanted for Messaging to be a part of Messaging "solution space" (to solve requirements of messaging process), so a different BC can use it (anti-corruption layer) without duplicating its logic into multiple BC.

Both scenarios are valid, first scenario tends to have other BCs depend on Messaging BC without duplicate code, and other scenario offers full autonomoty to each BC, no Messaging BC, "duplicate" code and probably higher usage of resources in that BC.

So could be a good way to define boundaries of a problem/solution space? Should it be based on certain DDD guidelines, limits of hardware resources, or something else?

Improve this question
2
  • Can you clarify whether Messaging does some marketing or customer communication, or is strictly internal?
    – Erik Eidt
    Commented Aug 13, 2016 at 15:29
  • @ErikEidt Messaging is just a trasnport mechanism that delivers, logs and archives any message type email, fax, sms etc. No real business logic there.
    – Dario Granich
    Commented Aug 13, 2016 at 19:23

1 Answer 1

Reset to default
4

The easiest way to determine a BC boundary is by looking at what terms in your current BC have multiple meanings in the real world.

For example, an Order to a person fulfilling inventory has a list of items he needs to have in store to send out. To a driver, an order might be nothing more than a truck and a destination.

Messaging sounds like a technical aspect of your solution and in that regards fits its own BC.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.