6 ms·
People have asked for evidence on this thread, so let me share my experience. A couple of years ago, I was developing an E-Commerce platformm internally for my
by neya 7y ago
People have asked for evidence on this thread, so let me share my experience. A couple of years ago, I was developing an E-Commerce platformm internally for my company. I follow Martin Fowlers' articles on using DDD (Domain Driven Design) and Microservices to architect applications. What should have been a month long project took us 8 months! I'm not including the time I took to read about, understand and practice DDD and the surrounding concepts. Every DDD book is atleast 500 pages or more. And none of them are clear on the concepts, and are mostly full of fluff.
To give you more details, our stack was based on Phoenix, but it used a concept called Umbrella applications (basically Micro services pattern). Along the way, I hit so many snags and I thought I must be doing it wrong. Because, that's what these authors kept saying all the time to people who had failed to implement their preachings. So, I met a couple of people who had actually done this DDD on a much larger scale than I had and even they shared the same experience and stories of failure and struggling. Still, I shrugged them off thinking it must be something we were doing wrong instead of DDD/Fowler's teachings itself. In the meantime, we were struggling to launch features for our E-Commerce software because our microservices architecture based on DDD was just a house of cards at this point. And then, I finally called up someone I knew who had done DDD successfully and asked him how he did it. He said one of the authors of a popular DDD related website, had offered to consult for his company. And they had no choice but to employ him because they were pretty invested at this point. After a while, I started meeting a bunch of such companies who got their DDD setup done by either authors or by some vendor these authors had a stake in.
And then BINGO, it all made sense - most of these patterns/shortcuts/discoveries/secret sauces by these authors are hardly tested by them. It's just a way to sell you more consulting and training.
A couple of weeks later, we hosted a casual meetup for tech talks in our area and we got to meet more folks who had followed the same path and failed. We finally decided to do a small hackathon over a weekend and get our projects done. In the end, in about 3 days from Fri-Sun, we had got done so much more with a monolithic architecture than we had ever gotten done with DDD and microservices. Today, my platform is in production and is a proud monolithic app and still going strong.
It was perhaps the most expensive lesson I've ever learnt, but one that I will remember for a long time.
- MiyamotoAkira 7y ago2015: https://www.martinfowler.com/bliki/MonolithFirst.html https://www.martinfowler.com/bliki/MonolithFirst.html
- deleted 7y ago[deleted]
- neya 7y agoI remember this article very well. When it was published, it was too late as we were already following his articles on DDD before that. This is what I meant when I said the authors said we were doing it wrong. This was published after realizing a lot of people who took these authors' advice and went down the DDD path weren't happy and shot themselves in the foot.
- balfirevic 7y agoThere is some ongoing confusion here. Using domain-driven design has no bearing on microservices vs. monolithic architecture.
- sooheon 7y agoWhat I find interesting about this anecdote is that if you give DDD proponents the benefit of charitable interpretation, they may genuinely have had your exact same journey in reverse. Maybe there is an inversion of the duckling imprinting phenomenon in software, where everyone hates the first terrible architecture they write, and when they finally get it right through lessons learned, preach that as The Way.
- meowface 7y agoExactly. That's what this breaks down to a lot of the time. A huge portion of software design, and discussion of it, is a lot more psychological and a lot less empirical or objective than it may appear. That's why you still see people at each other's throats pretty much every day on reddit and HN over pretty much every software design debate ever. (And software usage debates are even worse.) Their method is optimal and their opponent's is terribly overengineered or underengineered. People like to cling to their preferences, and prefer what they've moved away from when they were less experienced and skilled, or what people they respect use, or what happened to catch their fancy or fascination years ago, or just what makes them subjectively feel good. You see the exact same kind of thing in other disciplines, including artistic fields, and the exact same kind of discussion board vitriol and cargo culting. The nice thing is you at least get exposed to a lot of perspectives. If someone were to read only 1/4 of the posts in this thread, they may be convinced to take some kind of hardline position and find themselves down a narrow path. But if they read every post, they can take it all in and understand how much vehement disagreement and fuzziness there is, and be more skeptical and critical about the right or wrong way to do things.