What is a context boundary – really?

[Anette Hagberg]

This is posted on the DomainDrivenDesign group @ yahoo aswell.

There is a lot of hype with DDD, CQRS, context boundaries, entities,
aggregates - rooted or not - these days. All these buzz words are
flying around confusing people trying to grasp this. All the gurus
keep chanting: - “Listen to the client! They describe all the context
boundaries for you! All other verbs than CRUD holds the key!” Ok, so
I’m trying to understand this.

I come from the classic relational, N-tier world. And as former fan
or the third normal form, I have to rethink every entity and I come up
with. “Is this really an entity or just another id which is used to
tie things together on the query side?” Experts say: “Everything you
need to complete a command belongs to the same context boundary.”
Right, so now an order, item and product belongs in the same context
boundary? People all over are asking the same questions. How should
the Order aggregate root reference the chosen items and their
respective products? All Order needs is product id, how many items and
a user id. When billing says “We got paid”, send the order.

The Order goes through transitions. Doesn’t that mean that it is in
another context? Shouldn’t the boundary be a different one then?

Why shouldn’t it be called OrderRegistrant? And when the guys in
shipping packs the stuff, isn’t it in another context then? Could it
be that it’s should be handled as OrderShipper? What if it’s calcelled
somewhere? Could it be OrderCanceler? Is it law abiding to just handle
the context change as status property? Maybe the Order everyone keeps
talking about should really be a Saga waiting for all the right events
from the respective Order contexts?

Model context boundary based on the behavior. Well, is the context
boundary a thing with behavior or is it The behavior?

[Tom Janssens]

What kind of analysis do you use ? Start with BDD, and you get your commands and events for free.

An AR is just a class that groups together a series of command handlers that share state. Group your commands and you are halfway there...
A saga is a class that groups together things that happened in 1-n AR's (=events), or a timeout. It can publish a command if conditions are met. I tend to create a lot of small sagas respecting SRP.

If 2 AR's share a lot of saga's, it *might* be an indication that one of them is not an AR, but part of the other one.

You should not make it this hard; just do what your gut feeling tells you to do. The rules of CQRS are simple:

Command => AR.Command(command.parameters) => *Event
Event => *AR.Handle(Event)
*Event|Timeout => *Saga.Handle(Event|Timeout) => *Command
Event => QuerymodelBuilder.Handle(Event)

Due to the separation AR's come naturally, and cross-AR-transitions are explicit which makes it easy to spot problems in the flow or missing sagas, it also makes refactoring effortless.

Everywhere I look I see a lot of complicated explanations, I prefer KISS; if you use the CQRS approach, you do not need DDD, it comes naturally with it. I consider CQRS a methodology that makes it hard not to do DDD. Respect CQRS rules, and you will see your flow comes naturally.

One of the biggest benefits of CQRS is IMO that, due to the distinct separation, it does not cost you much if you make a mistake. Since everything is subdivided in small, manageable units, they are *a lot* easier to maintain/change.. CQRS allows you to fix errors easily. Errors are part of the learning proces; do not fight them, but accept them and learn from your mistakes.

[Wayne Douglas]

>Respect CQRS rules,

where would they be? i get the feeling they are the unwritten rules of
software development...

:)

On Thu, Jun 30, 2011 at 12:40 PM, Tom Janssens <d4s...@gmail.com> wrote:
> Respect CQRS rules,

--
Cheers,

w://

[Nuno Lopes]

In webster:

Context: The interrelated conditions in which something exists or occurs

Boundary: something that indicates or fixes a limit or extent

An Aggregate mantains set of consistent facts in which an entity or sets of entities exist by enforcing the conditions necessary for their existence. It is a surrogate of context. It also maintains a boundary since the set of facts is limited. Otherwise we would loose context.

“Everything you
need to complete a command belongs to the same context boundary.”
Right, so now an order, item and product belongs in the same context
boundary?

Say you have command, SubmitOrder. All the conditions that need to be met for its occurrence (OrderSubmited) should be kept by the same Aggregate.

All Order needs is product id, how many items and
a user id. When billing says “We got paid”, send the order.

It may need base Price, and other stuff. It depends on the conditions/requirements for its occurrence. The basic thing you should understand is that a product within an Order means a different thing then a Product in a Catalogue, in the Warehouse, in a Shipping Truck and so on. It's all about context.

The Order goes through transitions. Doesn’t that mean that it is in
another context? Shouldn’t the boundary be a different one then?

It depends how the domain processes each transition, language etc.

Maybe the Order everyone keeps
talking about should really be a Saga waiting for all the right events
from the respective Order contexts?

Maybe not the Order, but a Sale in complex cases. A Sale saga working as a coordinator of multiple context boundaries on a complex business process. Quite often is not needed.

And when the guys in
shipping packs the stuff, isn’t it in another context then?

Yes. It is useful to have a look on who does what in a process to establish context.

What if it’s calcelled
somewhere?

What if?

Model context boundary based on the behavior. 

In OO we use the word behavior as opposed to function or operation simply because an object holds internal state. This implies that two commands executed at different times with the same information may yield different results, the object "behaves" differently. That is why it is called behavior. 

In sum, they are telling you to use OO. Your Aggregate should defined has an Object as per OO terms.

Hope it helps,

Nuno

[Nuno Lopes]

CQRS is a pattern solving a specific set of system design problems. Much the same way as an Aggregate is.

Hope it helps,

Nuno