This actually happened to me a few years ago when I closed my consulting company. My bad, I know. My domain was taken over by someone in Vietnam. Back then, he was actually able to see my old emails via the Google Apps. Grandfathered free Apps accounts was a big part of the value proposition. He demanded $500 to delete my emails and docs. I offered $50 for his trouble since I recognized that I was at least partially at fault but he refused. To his bad luck, one of my main clients was Google itself. I reported him via my internal connections and the next day got the following email: "Oh my G-d, all forty of the domains I bought got Google Apps cancelled".
Readit Newsdvydra2 commented on Google’s OAuth login doesn’t protect against purchasing a failed startup domain trufflesecurity.com/blog/... · Posted by u/simiones
dvydra2 commented on Why I don't do Domain Driven Design (2018) tonymarston.net/php-mysql... · Posted by u/lr0
I've read several books on DDD and was on a team that fully bought into the idea and attempted to implement it for five years.
After all that, I think the concept of a ubiquitous language is excellent. Everyone should standardize on a common set of vocabulary. We even took it so far as to have a dictionary of our business domain terms. It's so obvious in hindsight that it seems completely foolish to do anything else.
The rest of the book is basically just one guy's preferred way to organize a CRUD codebase. You can use his preferred terms (entities, repositories, value objects) and put things in the "right places" based on how he really liked to organize the codebase on this one job he did. After trying sincerely to follow this book for five years, I now think this has very little value. I don't particularly care what he thinks is the difference a service and a repository. When we had a need that wasn't obvious from the book, we'd sit in on countless meetings of people arguing the definitions while quoting the DDD book like it's a sacred text. Endless bike shedding about one guy's favorite way to organize a CRUD app isn't a high value use of a team's time. Neither is spending weeks renaming and moving everything to match the perfect terms.
We bought into the idea that if we followed this guy's favorite organization, everything would be better. It wasn't. We spent a huge amount of time reorganizing 1.5 million lines of c#. I don't think we ever even gained a week back of that time. It was a huge waste of time for what? To feel good that we were following some book? We didn't reduce or remove any bugs. We didn't find it magically easier to add new domain logic, if anything it was harder because we had to debate every feature to ensure it was designed "correctly" according to the will of Eric Evans.
For example, look at this snippet from the article
> "Objects outside the aggregate are allowed to hold references to the root but not to any other object of the aggregate. The aggregate root checks the consistency of changes in the aggregate."
Imagine trying to read an entire book filled with this kind of language. Lots of new terms, special rules, and vague reasoning. It's perfect for creating an environment of religious debate.
Today I think that books (Riting Software is another) that just prescribe an organization are a waste of time. They promise benefits for just using new special terms and putting logic in the "right place" but then don't deliver. It's just one dude's preferred names for things, not a magic recipe.
A better option for learning architecture in my experience is books like "Structure and Interpretation of Computer Programs" that teach excellent fundamentals. Data structures, algorithms, functions, state lifecycles, asynchronous code, dynamic code generation, and DSLs are far more valuable and people rarely give them enough time. Once I got very comfortable with those fundamentals did architecture appear to me as just the same concepts repeated at a larger scale. Drilling fundamentals was highly valuable, and I wished I'd spent more time on those early instead of reading books about DDD.
Agree 100%. Its totally demoralizing to show up at work where folks are unable to hold a discussion from first principles. I've worked with Eric Evans. He is a brilliant engineer and I appreciate the effort he took to put his ideas into a book, but when I show up to work I expect the team to be empowered to chart its own course based on its particular context.
dvydra2 commented on Why I don't do Domain Driven Design (2018) tonymarston.net/php-mysql... · Posted by u/lr0
DDD is one of the most misunderstood "patterns" I've encountered. I started my career in the late 00s, and Evans' DDD/Fowler's PoEAA were treated by gospel as some, and I couldn't quite understand why. With years of experience, I now get it: software being built in 2003 was a lot different than software today.
DDD/PoEAA implicitly are about building long-lived, stateful thick clients -- i.e. a Java/C++ desktop application, because that's what people built by default in 2003. In the past 22 years, things have changed. The Bezos "API mandate" has either explicitly or implicitly been adopted by many organizations. Front-ends are much more likely to be websites/Chromium operating with stateless HTTP requests, instead of long-lived desktop applications. (React has "won" as the default JS framework over the past 10 years, and that has its own set of architectural patterns which don't mesh with DDD.) Backend software is built with a cloud-first mentality: servers can fall over at any minute, the application should scale up by adding more servers, etc...
All this leads to a much different approach. Statelessness is nonnegotiable, since you're dealing with stateless HTTP/GRPC requests that expose most or all of your functionality. The "anemic domain model"[0] is derided as an antipattern by DDD, yet it's the most sensible approach for dealing with objects that get loaded and disposed of with every request. Complex ORM schemes and patterns like "unit of work" are fine when dealing with small amounts of data, but break down when you start needing to care about e.g. splitting transactions into smaller chunks because writing 200,000 rows in a single tx is a bad idea.
I don't think DDD is useless, but its application is much narrower than advertised. It's a shame that even today people are still being taught from DDD as if it's the "right" way to code when for a large amount of modern software it's a terrible fit.
Well said! Designing from first principles is how we get ahead and outcompete those who are stuck in the past.
dvydra2 commented on EagerWords is Wordle for 2023 apps.apple.com/us/app/eag... · Posted by u/dvydra2
Eagerwords is fun and quite challenging.
I would explore a career as a Technical Quality Engineer. Feel free to reach out directly to david@vydra.net if interested.
Retool + Dark Lang
dvydra2 commented on Ask HN: Anyone making a living building desktop applications? · Posted by u/jventura
We are building and hiring at https://www.timebyping.com/
TimeByPing | Senior Software Engineer, Backend Services
Time by Ping (TBP) is in the business of returning time. We believe more time is wasted at work than anything else we do—and we are going to fix that. We’re beginning by automating timekeeping for the world’s largest enterprises (where time = money) and then using that time data to transform the way these industries price their services, and ultimately, get work done.
1