Bounded Context

[satish venkatakrishnan]

1)How do you define Bounded Context ? 

               My definition for the  particular concept is  " A Context which makes the communication clear between the developer and the Business  "

For eg  : i like to take a Quote System ,I am able to get three bounded context

1) Issue a Quote  -- because business always uses the term  "when i issue a Quote "

2) Purchase a Quote -- again business gives different business context here

3)Re-Rating the Quote 

So i like to take there as the Bounded context. Am i correct here... 

2) What are Modules in Domain driven design ? where it is used ?

[Sharas]

Will try to put it as simple as possible and without no "bird talk".

Bounded Context is a demarcation of a deployable, parallely implementable unit. It gives you benefit of independent action but brings costs of integration and translation. It's a divide-and-conquer view for project manager, depicted with Context Map.

As everything in DDD it should follow Model Driven Design, so BC should be meaningful to business and its name should enter ubiquitous language. In practice BCs can correspond to departments of your company like sales or marketing.

Module is a demarcation of semantic coherence and low coupling. It is not an artifact of project management like BC is. It is a tool to manage complexity in your BC. It's a divide-and-conquer view for developer. Names of modules also enters ubiquitous language.

[Nuno Lopes]

It's a divide-and-conquer view for project manager, depicted with Context Map.

+1

Nuno

[Jef Claes]

"A bounded context is where one ubiquitous language is consistent."

[Sharas gpavarde]

thats right, and monad is just a monoid in the category of endofunctors.

--
You received this message because you are subscribed to a topic in the Google Groups "DDD/CQRS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dddcqrs/BZfl7pJVhds/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Bryan Watts]

That made me chuckle. Caution, musings ahead.

Much information around Bounded Contexts is in terms of artifacts: models, ubiquitous languages, context maps, tech stacks, deployment strategies, etc. I prefer to work toward what it means to be within a context, and the purpose of a boundary.

I see a context as a place for making decisions and communicating the results to the world. A Bounded Context, as we are using it, is an area in which collaborators make decisions. The outline forms as we observe the decisions they make: what is common, what is different, who shares data, and why.

Pockets of overlap tell us about the relevance of one decision to another. A Bounded Context is a "best fit" around some decision points, within a sparseness tolerance. All elements of a Bounded Context work toward the same decision set, which determines Aggregate shapes.

A boundary signals a shift in consistency; crossing one affects data freshness. We have several boundaries in play:

- An Aggregate is the most consistent, as all of its data changes together

- Projections and (Workflow|Saga|Process Manager)s are eventually consistent, as they operate in response to Aggregate decisions

    - There is a natural delay in propagating changes

- A Bounded Context forms when Projections and Workflows collaborate with certain kinds of Aggregates

    - Organizing along these lines keeps SLAs low between Aggregates, Projections, and Workflows

- Decisions from outside the best-fit (by other Bounded Contexts) are less consistent with Projections and Workflows than Aggregates

So, a Bounded Context is the outermost boundary in a series of shifts in consistency, each of which affects data freshness at one or more decision points.

That abstraction has definitely helped me reason about domain models.