RE: Re: BoundedContexts

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.




-----Message d'origine-----
De : "Greg Young [email protected] [domaindrivendesign]" <[email protected]>
Envoyé : ‎05/‎01/‎2016 09:27
À : "[email protected]" <[email protected]>
Objet : Re: [domaindrivendesign] Re: BoundedContexts


  
Yes this uses the term bounded context as I understand it. The article does not seem to use the term bounded context in the same way.




My thought here is there may be homonym floating around, if so people should be careful to watch bounded contexts :)




On Mon, Jan 4, 2016 at 5:00 PM, [email protected] [domaindrivendesign] <[email protected]> wrote:



  
There is keynote from Eric Evans about microservices and bounded context: Domain-driven Design and microservices - JAXenter


 Domain-driven Design and microservices - JAXenter Eric Evans, author of the IT bestseller "Domain-Driven Design: Tackling Complexity in the Heart of Software", had some interesting things to say about w...
View on jaxenter.com Preview by Yahoo 





 












-- 


Studying for the Turing test