111–120 of 198 posts
Remember when people got offended by the "DDD" acronym? [1] "Good" times... [1] https://twitter.com/sarahmei/status/1073251153360482304
What's even funnier is that none of the acronyms listed there is a soft-porn reference as claimed in the twitter thread.
Reading about what it's meant to mean, it seems pretty common sense. As often implemented, however, it seems to lead to a lot of accidental complexity and a bunch of dubious usefulness abstraction layers.
I have a theory why this is. It seems that enterprise development as a field have a penchant for methodologies and acronyms. So, whatever silver bullet the enterprise-y shops get interested in eventually gets enterprisified. Be it UML, OOP, Agile, or DDD.
EDIT: I've found this an interesting read that sheds some more light on DDD using counter-examples:
Earlier quoted context omitted.
very basic common sense stuff, like understanding the business domain/keeping in close contact with the people who do. Much of DDD is common sense, what it offers is a way to be explicitly common sense. The important factors, the way I see it, is to explicitly make sure both developers and stakeholder have a shared mental model of the business process that maps to the domain in question, they all agree on which 'jarg…
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.
How complex your methodology around this has to be depends entirely on how complex the domain is and how many different definitions of "sold" is used with different parts of that domain.
Earlier quoted context omitted.
That's not what "Making illegal states unrepresentable" means. Let's say you're trying to parse a user object. Let's further say users always have to have a last name - a user without last name would be illegal state. Now if you're parsing some data for a user that really doesn't have a last name for some reason, there's two approaches to this problem - either you return a User with a null last name (which is essenti…
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.
Earlier quoted context omitted.
^^ These are the kinds of questions DDD has very vague answers to IME. It handwaves about all of the most critical aspects of software development. It's very specific that, for instance, your domain model "should only be created by factories", though. It's all a bit bikesheddy.
DDD provides insights to understanding how a business works for people who are not domain experts themself, and are tasked to translate business requirements to code. This insight helps make appropriate decisions about those "most critical aspects of software development", nothing more, nothing less. Whether you use factories or not is a much lower-level technical decision far removed from the essence and rationale o…
shrug maybe im reading all the wrong things but IME most DDD discussions, blog posts and books sound more like this:
https://stackoverflow.com/questions/555241/domain-driven-des...
And few delve into the real "essence" as you put it.
Event storming is one of few times, but it doesn't seem to be a core part of DDD and i found the outcome to be underwhelming.
Earlier quoted context omitted.
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?
I have a few ideas, in fact I gave a talk about that a long time ago [0], but I think one of my friends Marijn gave a good suggestion on twitter [1]: don't sell DDD, but fix your the problem your boss has. [0] https://www.slideshare.net/TomJanssens1/selling-ddd [1] https://twitter.com/huizendveld/status/1440683623628230665
Reasonable people (including DDD advocates) clearly understand that tactical patterns can easily be misapplied, and that the strategic part of it is more important, but inexperienced programmers jump in on the "new" fad (it's not even that new, which is most perplexing to me), and misapply all the patterns they possibly can.
I see there's a lot of similar sentiment here, so I think the question really is: how to convince inexperienced "converts" where the right boundary of applying tactical DDD solutions is?
The one time it worked is a very complex domain of insurance policy administration. It had highly complex business rules and had to maintain invariants. The original developers were all experienced and senior from a consulting company. I joined as a permanent member of the team before handover.
The problem was that over several years it was a hard time to get new hires up to speed to maintain the complex code and test it. Moreover even the ubiquitous language starts to change with new CEO, SMEs retiring, change in market etc. E.g. Member became Customer. Now you either refactor the entire codebase or have the code different to the new business jargon. Guess which one was chosen? Over time it became hard to refactor. I have now left the company many years back, but I am assuming this code still lives.
Then I worked in enterprises where this kind of core systems were built in some humongous monolith like SAP, maintained my an army of people from WITCH companies. All the digital apps, web portal etc. was a frontend, API and caching layer. The DDD complexity was in the bowels of SAP or PEGA or Dynamics etc.
Earlier quoted context omitted.
DDD technical patterns are a weird bunch. On one hand, there are quite a few smart concepts in there. Everyone should know what aggregates are, for example. On the other hand, many of them have little to do with the basic premise of DDD. You can have DDD without these specific patterns. On the third hand, people start applying every single pattern everywhere, like they did with GoF patterns.
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…
https://www.wiley.com/en-us/Patterns%2C+Principles%2C+and+Pr...
Earlier quoted context omitted.
> 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.
Ok, so in practice you are saying that no good programming paradigm exists. Where do we go from there?
Until then, we have to stick to patterns that are very simple, easy to teach and have wide pits of success. We also have to lean heavily on systems that easy to replace and easy to refactor, and can be managed by the few very experienced devs. That's why platforms like Ruby on Rails did so well, even though they can be divisive.
Earlier quoted context omitted.
Think about for example a planning component for hospital beds... There are a lot of parts that are really straightforward to implement, but for these planning components it might make more sense to develop an in-house component. (Assuming existing constraint solvers and/or rule engines are not a viable solution for you in this particular scenario.) If your business is talking about updating/deleting/inserting data,…
You clearly have some positive experience with DDD, and I'm definitely not trying to say that DDD is broken by design or anything like that. I'm sure there are successful and maintainable projects that utilize this design approach. Nonetheless, the only thing I could think of after reading your example is just how many subtle bugs and inconsistent behaviors this engine will have with various edgecases, so I'm still p…
This line of reasoning cuts both ways: how many bugs and inconsistent behaviors often pop up because developers rushed to write code without gathering enough requirements on the domain, how many productivity problems are caused by growing the system by accretion where it can, and how many rewrites were required just to fit the system's domain to the problem and shed technical debt from the accretion.