Re: Re: BoundedContexts

If you see it that way, then basically everything is a microservice.
That's one reason why that term is causing so much trouble.
I like (autonomous) component much more.

What I really don't understand, on the one hand you say "should embed 
business" and on the other "drive CRUD...". CRUD is an implementation 
detail, so it doesn't matter for defining the boundary for a Microservice.

What I'm missing in this thread is the IMHO most important aspect of a 
BC: it's a linguistic border.

What at first sounds esoteric is in practice quite clear very soon when 
you start talking about business concepts, and start arguing about the 
right context or definition. There you have a potential border.

So it doesn't matter that much if your Microservice does CRUD, embeds 
more or less business (it always should, why else you are doing it?), 
does technical tasks or whatever.
As long as the elements and concepts in the boundary aren't ubiquituous, 
you don't have a clean BC. That happens when you have legacy or started 
a new product, but the overlappings are always causing trouble. Just 
because the linguistic border is overlapping too, same or similar 
concepts in different contexts.
One of the main definitions of Microservices is that one team should 
build it. But if some of your concepts are spread over more than one 
team, well you guess it.

"Microservices aim at generalizing and reusing"?
No - the opposite.

Microservice are perfectly compatible with DDD.
I'd go even one step futher: if you don't know why you should have a BC, 
you are just building some ordinary services, but not Microservices.
Just because you are splitting something too big into small services 
with an arbitrary, questionable or, even worse, non-existent boundary.


Am 06.01.2016 um 09:04 schrieb Rénald VENANT-VALERY [email protected] 
[domaindrivendesign]:
> In my team, we sometimes use "Bounded Context" for services that are
> responsible for technical tasks (CRUD, ouch...). There is a lot of
> discussions around the way we should name things. I promote the idea
> that a BC should embed business, and should be "infrastructure and
> deployment ignorant".
>
> We also use "micro-services" to drive CRUD operations and very atomic
> tasks, and I now think that micro-services and DDD are not compatible.
> Micro-services aim at generalizing and reusing, DDD aim at specializing
> (it is my opinion, just based on my personal experience...).
>
> In many teams, many developers are very interested in mastering
> micro-services, to pin hype things on their resume, and it is pretty
> clear that they sometimes "borrow" the DDD vocabulary to legitimate an
> approach that is driven by personal engineering purposes, rather than
> business needs.



------------------------------------
Posted by: Nino Martincevic <[email protected]>
------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/domaindrivendesign/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/domaindrivendesign/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/