Geek, agilista, blogger, codefella, serial reader. In the daylight - I navigate & lead software engineering. #lean #design #aws #elixir #analytics. I speak here for myself only.
My #confspree continues - this time I've invaded Budapest to participate (as a crowd fodder) in Craft [http://craft-conf.com/2014/about.html] - two-day long conference about software craftsmanship (surprise! surprise!). It was the first edition of Craft, so there was a chance that the whole thing...
Last few weeks have been quite busy for me and my gang of Merry Men. We're doing a lean project of development architecture refreshment for a large enterprise and we're not wasting time - we aim to deliver the changes as quickly & frequently as possible...
This is part III of coupling consideration topic. If you want to check my past coupling-related posts, you can find them here: * Part I [http://gebski.tumblr.com/post/76150235763/the-silent-assassin-that-knows-no-mercy-how] - the theory of coupling * Part II [http://gebski.tumblr.com/post/77632428220/the-silent-assassin-that-knows-no-mercy-how] - practical examples of coupling...
If you know me in person, you most likely already know that I'm batshit crazy about DDD (Domain Driven Design [http://en.wikipedia.org/wiki/Domain-driven_design], not Degenerative Disc Disease ...). As DDD is the kind of topic everyone speaks about but only few actually use this method...
The idea of ownership may be tricky and gets easily misunderstood or excessively exaggerated (some would say - demonized), especially by Agile dogmatists and people with limited imagination: I never said those two groups are the same though :) That's why I'd like to be perfectly clear...
Once again, I had some plans for the post, but the brutal life has forced me to change them and write about something else - the real life situation I've encountered today has reminded me some past discourse about what actually is a true border between being amateur...