RE: Re: BoundedContexts

The aim of my term "should embed business" was to say that if there is no business in the BC (in a DDD manner), there is probably no BC because it is probably at an infrastructure level. When drawing Contexts Maps, or the functional architecture, these "so-called BCs" will not necessarily appear.


I had a lot a discussion with ALM Rangers in my team and CIOs (my role is Enterprise Architecture) and we finally came to an agreement by saying that micro-services are a good fit when/where DDD fails. By DDD I mean the "keep it simple" part of the toolbox. If BCs can't be designed in a way that keeps things clear and simple, break them !


One more point (in my opinion/experience) : I work in a FinTech and our business-rules are so complicated that there is no place for micro-services (or maybe a few ones). We changed the way to design our system because we saw that micro-services that do not have a BC that really match a "business area" recreate centralization and high-coupling with the rest of the system. So, as a conclusion, there is in our situation no micro-services architecture. The few existing micro-services are about sending mails, printing pdfs... (something that is more about infra than business). In the system, there are just BCs exposing business-services where middleware does not fit. I think that it depends on the context, but our situation, we found some consensus by defining these practices (it was a big victory... 😊).






-----Message d'origine-----
De : "Nino Martincevic [email protected] [domaindrivendesign]" <[email protected]>
Envoyé : ‎07/‎01/‎2016 03:35

À : "[email protected]" <[email protected]>
Objet : Re: [domaindrivendesign] 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.