141–150 of 198 posts
I think domain driven design is born to differentiate with database driven design. So we design at a higher level, our thought process, vocabulary is tied with business terms.
That was like 25 years ago.
We use DDD at the current company I work in and to be honest, I detest it so much that sometimes it makes me wonder if I even want to continue in the programming space (been at it for 20 years). Don't get me wrong, DDD has meaning and purpose, but some companies are applying it as a badge to be obtained instead of pondering the question, do you really need to rewrite everything following DDD? In our case, simple CRUD…
> Now, you could make the argument "You Are Doing It Wrong(tm)" I always hate these arguments - for me, whether a particular programming paradigm is 'good' or 'bad' for an organisation comes down to: "what will my least senior developer do with this?". If it tends to produce tangled nightmares, then it's not a good paradigm, it's about how the weakest link will use it, not the strongest ones.
We use DDD at the current company I work in and to be honest, I detest it so much that sometimes it makes me wonder if I even want to continue in the programming space (been at it for 20 years). Don't get me wrong, DDD has meaning and purpose, but some companies are applying it as a badge to be obtained instead of pondering the question, do you really need to rewrite everything following DDD? In our case, simple CRUD…
Hugs. I'm sure we've all suffered this Kafkaesque torture. But it still sucks.
Have you heard of the CIA (nee OSS) book on Simple Sabotage Field Manual? http://www.simplesabotage.com
It predates Brazil, Office Space, Dilbert, etc. After reading this book, and observing management, it's hard to imagine it's not all deliberate. There's just something inherently evil in bureaucracy.
> ...you could make the argument "You Are Doing It Wrong™"
Ages ago my company's study group tackled Applying Use Cases: A Practical Guide. https://www.amazon.com/Applying-Use-Cases-Practical-Guide/dp... After all the monkey motion with UML, schemes, design patterns, etc, this book was like a clarion blasting away ignorance and ambiguity.
It was so clear. Do the use cases. Then directly derive architect from those use cases. Voila! Impossible to fuck up.
However. Young me learned a very valuable lesson.
Nothing is so obvious and virtuous and good that some whackadoodles cannot, will not comprehend it.
But why?
Obstinance? Actual confusion? Inability to suspend disbelief? White knuckled desperate grasp on prior beliefs? Fear? Moral and philosophical opposition? Refusal to concede control (power)?
I have no idea why.
Whatever the root cause, I've experienced these impasses so many times, I've simply given up.
I eventually learned to do whatever it takes to publicly appease the tyrannical gods of confusion, then do any actual work as able on the down low.
Earlier quoted context omitted.
Nope, still means nothing too me. I'll just accept that how this bucket of words is supposed to form some cohesive methodology or pattern for anything is beyond my understanding. I'm sure some people get paid a lot of $ to implement it tho.
Simple Version. Before writing a function that reports how many of a certain thing has been "sold", make sure everybody involved agrees what "sold" means in this specific context and domain. And once you have agreed, make sure that every time a function, variable or database table talks about things "sold" it's using that definition. How complex your methodology around this has to be depends entirely on how complex t…
doStuff({soldFromSys1, soldFromSys2, soldType, price, priceType, priceTypeIdKey, customer})
¯\_(ツ)_/¯
We use DDD at the current company I work in and to be honest, I detest it so much that sometimes it makes me wonder if I even want to continue in the programming space (been at it for 20 years). Don't get me wrong, DDD has meaning and purpose, but some companies are applying it as a badge to be obtained instead of pondering the question, do you really need to rewrite everything following DDD? In our case, simple CRUD…
I read a bit about DDD but never really went in-depth with it, like I never read the book or anything. Instead I just try to absorb the major takeaways that I got from what I've read: 1. Bring in people with domain knowledge to help you understand the expected behavior of the system. 2. Try to establish a consistent language that is used in both verbal conversations as well as code. I feel like those are good, easy-t…
It's a godsend for the top-down inside-out approach of requirements engineering that I like and teach.
Then I met some people the actual local DDD meetup group and was shocked that that part basically made up effectively zero percent of their discussion and the rest was taken up by talk about adapters, hexagonal architecture and all kinds of artificial design patterns that cultivate complexity and self-importance. I've been careful to call myself a DDD advocate ever since.
IMHO DDD went through the same unfortunate descent that Agile did: An originally really great idea and common-sense approach that went on to get bastardized into a cargo cult by coaches who like to produce sheets for BS bingo.
Earlier quoted context omitted.
I'd advice people new to DDD to involve themselves with understanding the Strategic Design parts first. The rationale, pros and cons for using it etc. And stay well away from tactical patterns until you know the role of DDD wrt the objectives you want to achieve. Strategic vs. tactical are completely different concerns. The problem with a lot of DDD information is that people tend to dive into tactical way to early a…
I found this book very good in that regard. The first half of the book is on strategy and emphasizes its importance. It also makes it clear that only a subset of your system is suitable for DDD (for example, not the CRUD bits). I also found it much clearer and less verbose than the Evans book. https://www.wiley.com/en-us/Patterns%2C+Principles%2C+and+Pr...
Earlier quoted context omitted.
Tactical/technical DDD patterns should only be used for parts of the code where there is a lot of business agility required, so the behavior of your code changes a lot, and you have a tight feedback loop with your business unit. Your story sounds like they implemented a "technical DDD top-level architecture" (TM), whatever that may be. (I'd assume layers of abstractions coupled with logic spread all over the place, w…
Any tips on to persuade a stakeholder , senior leader, or your team lead that their area of focus is not a core part of the business without them feeling defensive about their status within the company? Any tips of how to do DDD when every area is considered a core priority of the business because uncomfortable conversations are hard?
"There is some benefits to what you're proposing. My primary concern is cost. I see no technical difficulties with doing it , and one of the benefits of that is that you'd have it ready in a tenth of the time. If I'm wrong, we can always change our minds and build it your way. That would barely take any additional time at all, since what I'm proposing is so simple to begin with.
"So, what do you say? Would you like to try to get it done by November, or should we labour over it until next June? If I understand the business figures right, if we can get it out in November, we'll make $6,000,000 more – and it would all be because you made the right technical decision here."
So this is a very fundamental explanation of DDD, the kind you might learn at university. But the last time I researched DDD there was a very concrete architecture associated with it, and I didn't really understand why. Every DDD article would also introduce CQRS for some reason, it seems they are inextricably connected, at least for web application development. Anyone got a good story on that?
Unfortunately there isn't a single definition of DDD accepted by everyone. At its core DDD is about the practice of software design which puts Domain - user language and problems - first. There are no technical considerations. ES (Event Sourcing) and CQRS are technical patterns people like to use while doing DDD because of various reasons, but they're in no way required to practice DDD.
To those experienced in DDD: You can do DDD without CQRS? And you can do CQRS without it being DDD too? This is not clear to me as an observer.
Earlier quoted context omitted.
Simple Version. Before writing a function that reports how many of a certain thing has been "sold", make sure everybody involved agrees what "sold" means in this specific context and domain. And once you have agreed, make sure that every time a function, variable or database table talks about things "sold" it's using that definition. How complex your methodology around this has to be depends entirely on how complex t…
What's so novel about this that deserve its own name and writing a book about this?
Earlier quoted context omitted.
But clearly, requiring a last name is wrong. If legitimate users can lack a last name, the system needs to work without last names: probably there should be a flexible "person's name" class that encapsulates first names, last names, titles etc. instead of attaching a raw last name to users.
... more like a "getPersonName()" method instead of a whole 'nother class, init?
There should be only one place for name-handling logic, and since other people types besides users could appear in the domain model (commercial customer, social network "friend", relative, etc.) the user class isn't that place.