That particular piece is by Udi Dahan, Founder & CEO, Particular Software. The talks given by his employees can be interesting as well.
In particular finding your service boundaries comes to the conclusion that startups have difficulties identifying boundaries because their business rules aren't stable - which means that μservices are not a good fit in that situation.
And it's in bounded contexts (which is what microservices are all about) where naive application of DRY (or overzealous pursuit of reuse) can be counterproductive. Note that both the sales context and the support context have their own version of Customer and Product.
While sharing the same name these entities will likely have a very different shape inside each context as they support very different roles. Unifying them into one single entity would only increase coupling, undermining the autonomy of each context. Instead representations of Customer and Product that are shared between contexts are minimal - just enough information to correlate the support version with the sales version.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Software Development By Slogan usually does.
Don't Repeat Yourself is a slogan that refers to:
When phrased that way, "duplication" has a lot more nuance.
The Wrong Abstraction
YouTube
I really like that phrasing. Thanks for sharing that article :D
I'll also use the chance to throw in a link to one of my favourite programming books: 97 things every programmer should know, thing 7: beware the share
That particular piece is by Udi Dahan, Founder & CEO, Particular Software. The talks given by his employees can be interesting as well.
In particular finding your service boundaries comes to the conclusion that startups have difficulties identifying boundaries because their business rules aren't stable - which means that μservices are not a good fit in that situation.
And it's in bounded contexts (which is what microservices are all about) where naive application of DRY (or overzealous pursuit of reuse) can be counterproductive. Note that both the sales context and the support context have their own version of
CustomerandProduct.While sharing the same name these entities will likely have a very different shape inside each context as they support very different roles. Unifying them into one single entity would only increase coupling, undermining the autonomy of each context. Instead representations of
CustomerandProductthat are shared between contexts are minimal - just enough information to correlate the support version with the sales version.