Twitter quotes: Business Components versus Bounded Contexts
— Last updated 2012/02/15
Twitter exchange on “Business Components versus Bounded Contexts” after the blog post: Udi & Greg Reach CQRS Agreement
Eric Evans
Fundamentally, in #DDD, a Bounded Context is linguistic: a part of the system/project where language is consistent and rules agree.
— Eric Evans (@ericevans0) Février 11, 2012
bit.ly/udigreg says ‘Business Component’ is in 1 Bounded Context. Def of B Ctxt doesn’t say this IS so. In good design SHOULD be so
— Eric Evans (@ericevans0) Février 11, 2012
@Bemafred Distinct concepts. Good separation of concerns allows you to deal with diff concerns in diff contexts. Must see contexts as-is
— Eric Evans (@ericevans0) Février 11, 2012
thinkb4coding / jeppec
@thinkb4coding Seems you have the hands down on Business Components versus Bounded Contexts. Can you clarify on udidahan.com/2012/02/10/udi… — (tweet)
@jeppec it’s true Thar there’s few words about bizcomp on the blogs for now — (tweet)
@jeppec from my experience BCtx contains several smaller services that represent Business units that are impl separately — (tweet)
@jeppec this are the business components, that have different users, dev/deployment lifecycles.. — (tweet)
@jeppec it’s a level between bounded context and aggregates. They group services that work together to provide a business unit — (tweet)
@jeppec the c/q segregation happens at this level. Neither at the top level, neither at the bounded ctx level. It’s too large — (tweet)
@thinkb4coding that sounds reasonable and I think most CQRS users do this. But when did the business component term get defined? — (tweet)
@thinkb4coding Such as Usecase specific services (eg. different clients/users might have special needs/flows). Makes sense? — (tweet)
@jeppec yep. I think udi talks about it in his course. — (tweet)
Udi Dahan
Confusion around Bounded Context / Business Component is influenced by the first being solution domain, second being problem domain…
— UdiDahan (@UdiDahan) February 14, 2012
@UdiDahan Subdomain is already used in problem space when doing domain assessment. Why not stick with that and not introduce ambiguous term?
— Vaughn Vernon (@VaughnVernon) Février 14, 2012
DDD doesn’t try to enforce alignment between solution and problem domains
— UdiDahan (@UdiDahan) February 14, 2012
@UdiDahan Are you saying that problem domain exists inside a Bounded Context? Thought you said Biz Component was inside, sounds solution-y.
— Vaughn Vernon (@VaughnVernon) Février 14, 2012
That’s where we get into trouble using DDD terminology to describe a specific form of good design that enforces alignment
— UdiDahan (@UdiDahan) February 14, 2012
@UdiDahan a particular form of good design is supported by aligning Bounded Context 1:1 with Subdomain. But also supports less good design.
— Vaughn Vernon (@VaughnVernon) Février 14, 2012
It turns out that I didn’t represent @ericevans0 Bounded Context correctly. He allows for them to be a problem or solution domain construct.
— UdiDahan (@UdiDahan) February 15, 2012
