16 ms·

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 programmin

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 APIs that in "regular programming" might take a couple 200 line files have turned into unmanageable nightmares in DDD that take you at least a couple of days of really intensive investigation to understand, because it have been divided in more that 25 files that hold 3 or 4 lines of code at most, with so many abstraction layers that it's impossible for the best of us to follow in one go. Now, you could make the argument "You Are Doing It Wrong(tm)" but since I'm just a drone in this specific scheme and there's no wiggle room for anything (the team is quite inflexible on this) I have to follow it to the letter. Just giving my two cents, again, not depreciating DDD, it has its purpose but in my opinion, it's for very specific projects.

macando 5y ago
> it have been divided in more that 25 files that hold 3 or 4 lines of code at most, with so many abstraction layers that it's impossible for the best of us to follow in one go. When you put engineers in charge you get overengineering and when you put managers you get underengineering. Is there a way out?
- oscarcp 5y ago
  At the moment, there's no way out, plannign stipulates that all our microservices must be rewritten to accomodate this super abstract DDD design (and youy're right, it was an engineer who created our current layout)
- deleted 5y ago
  [deleted]
- tragomaskhalos 5y ago
  This is so true, and has been forever. In the early 90s I worked on a system where you couldn't just write structs, rather you had to submit their definition to a guy who entered the details into a database, and there was a daily run to generate the C header files from that database. To this day I'm convinced the only reason it was done this way was that it could be done this way.
  - macando 5y ago
    It's an over-reliance on ceremony. On some days I think it's a character trait.
  - lgvld 5y ago
    Ouch! Crazy ;-)
- deleted 5y ago
  [deleted]
- mytailorisrich 5y ago
  > When you put engineers in charge you get overengineering This means you picked the wrong engineers. An engineer's job and skill is to be able to make this sort of call. The same goes with managers or any other role. So the way out is always to carefully select experienced, competent, no nonsense people.
- andi999 5y ago
  Getting experienced senior engineers, probably they have seen both; and in the best case they have worked on a middle ground project so they experienced how to do it and how not to do it.
  - macando 5y ago
    Experienced and exposed to areas outside their main expertise so they are well rounded and pragmatic.
  - moonchrome 5y ago
    I think you need to have a few of those "I've use this pattern and had to stay up 24 hours to meet a deadline because shit was way too complicated for the delivered value" to instil a healthy fear of overcomplicating solutions. I've worked with developers with 5+ years of experience that haven't went trough that (either corporate culture allowed them to deliver minimum value in 5 days or jumping projects before it gets to the WTF stage of complexity). It's hard to learn if you never get burned.
- rapnie 5y ago
  > When you put engineers in charge you get overengineering and when you put managers you get underengineering. Is there a way out? The whole idea is to bring them together "in the same room" and allow common understanding of the domain so they stay on the same page throughout the project. Then they'll do each what they are best at (managers whip up glossy slides, and devs crank out reams of code ;)
NicoJuicy 5y ago
If it's just crud. Create a minimal API that handles it to show the difference. Which programming language? There was some work shown in .net recently
- oscarcp 5y ago
  Python, FastAPI... so you can imagine how something as simple as a CRUD becomes quickly impossible to manage as soon as you ignore everything and start creating repositories, queries, use cases, etc. for a single endpoint. I agree with you that a minimal implementation should handle it but... someone had wet dreams with DDD and everything has to be DDD now :)
  - NicoJuicy 5y ago
    And for something like "translations crud" this shouldn't be required ( which service needs to be updated from a translation update?). Perhaps that's a perfect example to implement it and push it. ( depends on how far you're willing to go and push back against who) Look for a fancy name to describe the "pattern" could help.
ToJans 5y ago
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, without any added benefit.) You see this a lot when people read some stuff about DDD, and they start experimenting with the technical/tactical patterns, because this is the aspect that makes most sense to a technical audience. In reality the tactical/technical DDD patterns should only be applied in the core part of your business (i.e. the thing that gives you a strategic advantage over your competitors.), because that typically needs to change a lot, so having a common language/model with the business tends to be worth the extra upkeep required when opting for more flexible models. Identifying what the core part is of your business (most likely it's not authentication, billing, invoicing, content management, ...) is one of the more important (and most difficult) aspects of DDD.
- oscarcp 5y ago
  > 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, without any added benefit.) Exactly :)
- y4mi 5y ago
  > In reality the tactical/technical DDD patterns should only be applied in the core part of your business [...] I cannot imagine anything where it would make sense unless you're implementing an actual framework such as Spring in javaland. And at that point I'd say you're wasting effort and just using spring boot should be preferable. It does make sense with these super low level frameworks though, but which corporation makes them in-house at this point?
  - ToJans 5y ago
    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 are not describing the actual reasoning behind the change. For DDD, it makes sense to figure out why exactly you are doing the things you do, and model these explicitly in your systems for those parts that matter. The stereo-typical example for this is an address change: if you model this as an "AddressUpdated", you might as well use CRUD, as this does not specify the intent of the change. You could change an address because it contained a typo, but you can also change it because someone moved. These might lead to different outcomes, so in DDD you would typically model these as "AddressTypoCorrected" and "ContactMoved". There are other fine-grained aspects, for example the need of an identity for an object: physical money is considered a value object (so it has no specific ID per instance) in almost all contexts, unless you are the national bank: all of a sudden the identity (serial number of the bill) does matter, so the same "thing" might have different "models" within different parts of the business. Other examples might be value objects for specific areas, for example weight. Typically weight starts out as a number, and all of a sudden there might be a need to add a precision, mark it as an estimate, or have it "unknown". In order to avoid if-statements all over the code, you construct a "weight value object" that properly manages all of these peculiarities in a single place (i.e. what's the result of an estimate+undefined etc.)
goto11 5y ago
Developers will destroy everything good! DDD has some great ideas about how to model things and talk about things. But it is not a concrete architecture prescribing a particular number of layers or lines of code.
- JackFr 5y ago
  I read a preprint of Eric Evans book before it came out, and then bought a copy when it got published. As someone who had been in the industry 6-7 years at that point, it really resonated - he was describing modes of success and failure I had seen but didn’t really have names for. Much of the usefulness of the book was just to put names on these things. What has happened to ‘DDD’ in the meantime surprised me. It never occurred to me from the original book that a methodology of strict practices could emerge from it. To me that wasn’t the sense if it at all.
pydry 5y ago
I noticed something similar. A minimal PR to introduce DDD on our code base ballooned the codebase by something like 1,000 lines, smattered all over the code base. I think it would have ballooned it by about 12-15,000 in total in the end if we'd used it everywhere. That would have been fertile breeding ground for bugs. The ideas made sense on logically complex code that required frequent refactoring, but the strict separation between all the different layers simply led to a lot of code in most instance. Far too much. We also couldnt agree on where the limits of the bounded contexts really lay. Most documentation on this issue is a mere handwave saying "you figure it out" or "it'll become clear when you do these exercises with the business" (it didnt), which is odd given how vitally important it is and how damaging it is to bound the wrong things.
- dm3 5y ago
  > We also couldnt agree on where the limits of the bounded contexts really lay. Most documentation on this issue is a mere handwave saying "you figure it out" or "it'll become clear when you do these exercises with the business" (it didnt), which is odd given how vitally important it is and how damaging it is to bound the wrong things. This is the hardest part of software design. No wonder there are no clear cut rules on how to do it. You have to be both a domain and implementation expert to get the boundaries right on the first try.
  - pydry 5y ago
    Yeah, it is tricky. I've rewritten many a code base because I drew the original boundaries in the wrong place and their logical locations only became clear in retrospect. I'm not so convinced that it's something you can get just by better communicating with "the business" either. This is partly what infuriated me so about the extreme amount of code required to follow DDD patterns - 3-4x the amount of code means 3-4x the cost of that rewrite if you get the boundary wrong.
    - dm3 5y ago
      I find the original tactical DDD patterns as useful as the gang-of-four OOP patterns these days. Modern languages made the latter irrelevant. Modern DDD practice emphasizes getting the strategic aspects of DDD right: language and boundaries. Doesn't matter if your code has a type named `Aggregate` in it. Matters if you get your consistency boundaries right. > I'm not so convinced that it's something you can get just by better communicating with "the business" either. I don't have a good answer for this. I personally try to keep my modules small so that there's not more than a ~week worth of stuff to redo if understanding of business (or business itself) changes. I often fail too.
blowski 5y ago
I call this “domain driven design driven design”.
ajuc 5y ago
I signed for a course on DDD thinking it will be about Data-Driven Design. It was about Domain-Driven Design and it's like the exact opposite. Data-DD is focus on data and keep it simple. Domain-DD is another one of these architecture astronauts fads where you introduce new abstractions and then spend most of the time wondering whether penguin is a bird or a fish for the purpose of your application.
- rapnie 5y ago
  > Domain-DD is another one of these architecture astronauts fads where you introduce new abstractions Reading this I guess you followed the wrong course. One that shoved you Tactical Patterns down the throat without explaining well-enough why you should use them. DDD in the core is not about architecture, but about *common understanding* of the domain, *before* you start coding and hacking on a particular architecture. The domain understanding should help you make appropriate architecture decisions, but in now way dictate what architecture designs to use.
- rewma 5y ago
  > Domain-DD is another one of these architecture astronauts fads where you introduce new abstractions and then spend most of the time wondering whether penguin is a bird or a fish for the purpose of your application. That doesn't sound right. Domain-driven design is just a technique to design a data model that fits your application domain, and designs the whole application around that data model. To put it differently, with DDD first you define a data structures, and afterwards the application is just operators over said data structure. The only reason why in DDD you would care about whether "a penguin is a fish or a bird" is if your businesses required handling fishes or birds in fundamentally different and incompatible ways, which would require you to write special purpose code that crossed all layers. It sounds like you've been experiencing a kind of analysis paralysis with the DDD tag.
AndrewSChapman 5y ago
DDD doesn't prescribe any structure really, other than saying you should separate out different contexts and use unified terminology throughout the business, which I don't think anyone would argue against. Are you talking about design patterns by any chance? Maybe things like repositories, adapters, small and focused service classes and the like?
- bamboozled 5y ago
  If it’s really that simple, why are do bible sized books written on the topic ? Why does it even need a name if it’s just common sense ?
  - qaq 5y ago
    Cause consultants need to make $.
  - AndrewSChapman 5y ago
    Don't get me wrong, I'm no DDD expert by any stretch. I think the main topic and real difficultly of DDD is figuring out specifically where and how to separate out different contexts (the so-called 'bounded context' in DDD parlance). Creating microservices is a good example. Where should the responsibility for a single microservice start and finish? What might the implications for scalability and extensibility be? What does this mean for data storage? What data will be shared or replicated between microservices and how will this be done? Answering these kinds of questions is hard and has big implications for your teams and for your business.
    - pydry 5y ago
      ^^ 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.
      - 5y ago
HelloNurse 5y ago
In a typical pattern of buzzword adoption, your horrible architecture isn't DDD just because someone calls it so; it's just bad design. In particular, pulverized source files and excessive abstraction layers are characteristic symptoms of dogmatic, value-oblivious impractical design: quite the opposite of thinking hard about a meaningful domain model in order to use it as a shared language.
- orthoxerox 5y ago
  Exactly like agile, which has morphed into following the rules of the latest Agile Framework.
deleted 5y ago
[deleted]
davedx 5y ago
My experience too. “No silver bullet” is correct. DDD has some value but the cargo culting of it gets pretty ridiculous in some places.
malka 5y ago
Is this your project ? https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
ChicagoDave 5y ago
DDD principals should only be applied to reduce complexity. If the problem space is really just crud applications, DDD modeling or engineering is a waste of time and money. But here’s where you have to be careful. It’s still useful to go through things like Event Storming and modeling domains to understand the problem space before deciding that basic crud is good enough.
- lievendoclo 5y ago
  I've been coding for over 15 years now and everytime someone says "Nah, we only need CRUD", they end up eating their words a couple of months down the line. The net result: domain logic all over the place. People tend to think that applying DDD infers a tremendous overhead in the code. That doesn't have to be the case. However, some tend to go overboard and that's when I can understand the frustration.
  - JackFr 5y ago
    Quick-and-dirty is always dirty and rarely quick.
mathiasverraes 5y ago
I'm sorry you're having that experience. DDD is specifically aimed at tackling complexity, as it says on the cover. Part of the problem is that complexity is relative to the observer, how experienced they are in that particular domain, etc. Good abstractions make complexity manageable, bad ones create more complexity. And that's another problem: a domain might be quite straightforward but bad explanations, missing information, bad abstractions, etc can make it seem more complex. Your colleagues need to remember that DDD is supposed to be applied pragmatically. If the structure causes more navigation work than needed, simplify it. If the problem could be solved with a simple CRUD system, do that. If most of the problem is CRUD, but there's one particularly complex bit that changes a lot and requires a lot of flexibility, isolate that part, so that the simple and complex parts can have a simple integration, don't leak into each other, and can evolve at their own speeds.
- rewma 5y ago
  > I'm sorry you're having that experience. DDD is specifically aimed at tackling complexity, as it says on the cover. Part of the problem is that complexity is relative to the observer, how experienced they are in that particular domain, etc. I'd say part of the problem is that DDD critics conflate DDD with overly complex, enterprisey models that don't match their personal preferences on the acceptable tradeoffs between complexity and correctness. As DDD comes up sounding like too much work to implement too much complexity that brings too little value, they flag it as a concern. What I believe is missing from this discussion is the scenario where DDD practices are not followed and consequently teams are forced to iterate and reimplements projects or parts of it just to fit requirements that emerged because some aspects of the domain model weren't looked into. Design by accretion is largely accepted, as is technical debt, but they do have a cost.
  - oscarcp 5y ago
    You make quite the point here. That is the advantage I see for DDD; you have dependency on service that may change, DDD will make your life easier when switching, otherwise there will be weeks of rewriting code. And what happens during transition times (thinking about CRM for example) where you have to keep connected to both systems?. This said, in my situation it's like trying to kill flies with a muon cannon (fyi. this gun is fictional and it's exaggerated to drive the point), it's cool'n's*it but the same could have been done with a newspaper or your hand. To maintain the muon cannon you need the entire Fermilab team, your hand... well, it's your hand. Apologies for the exaggeration, can't avoid it :D
afurculita 5y ago
You don't use DDD at your current company. Naming it DDD doesn't make it DDD.
- ratww 5y ago
  That's the "No True Yorkshireman" fallacy. In my experience it's extremely safe to assume that, even with the best intentions, DDD code can become stupid big balls of mud.
nathias 5y ago
This is exactly the state of a project I'm working at, but without DDD and with microservices instead. It is probably more of a general problem of complexity growth that happens when anything goes wrong with architecture and isn't addressed properly not just a consequence of bad DDD.
sweezyjeezy 5y ago
> 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.
- mnsc 5y ago
  Ok, so in practice you are saying that no good programming paradigm exists. Where do we go from there?
  - sweezyjeezy 5y ago
    I agree no paradigm is particularly great for beginners - OOP leads to junior devs separating their code prematurely/inaccurately, writing horrendous inheritance trees etc., functional programming can lead to some really opaque code that feels like you're trying to solve a puzzle when reading it. I do think good principles exist however: - try to write code that can be easily unit tested - composition over inheritance - immutable over mutable + avoid side effects - avoid recursion unless your data is recursive etc. etc.
  - pydry 5y ago
    Certainly no good general purpose programming paradigm exists. Nor will it. The more general purpose it purports to be the vaguer and more misapplied it will end up being. DDD could be a lot better as a movement if it tried to limit its scope a bit.
  - shados 5y ago
    Wait until the market stabilizes and new dev don't outnumber more senior ones 10:1. 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.
  - 5y ago
Jenk 5y ago
Much like most things engineers bitch about, the tool isn't to blame here (as you say yourself) - it's the wrong tool for the wrong job. There's nothing about DDD that says you can't make a simple CRUD API, if that's all that is required. DDD's principle value is one of ubiquity (sold as "Ubiquitous Language" but I posit that "Ubiquity" is more accurate) - does your code do what the organisation does, and vice versa? Not just using the same terminology, but using the same workflow. Now if what the organisation does is basic stuff, then your code should be basic, too. If there is an asymmetry between what the org and code do.. there's pain.
bjornsing 5y ago
> more that 25 files that hold 3 or 4 lines of code at most That sounds kind of annoying, but not very hard to understand.
tenaciousDaniel 5y ago
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-to-understand principles, and I've never understood why the whole DDD space is taken up by this insanely complicated terminology and theory. It's so off-putting.
- endymi0n 5y ago
  This is exactly spot on and my go-to approach as well. I always thought myself of a huge fan of DDD, simply because I think it makes so much sense to discuss the architecture directly with the stakeholders until everyone technical and nontechnical alike really agrees about the existence, relation and constraints of entities: By using common, ubiquitous language and just giving the same things the same consistent, common-sense names while giving different things different names. 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.
  - ratww 5y ago
    Yep, exact same experience. I also had the unfortunate experience of working with some die-hards who believe DDD dictates that "the code and only the code should reflect the business requirements 1:1", with emphasis on the "only". Which means that things that are often configurable in other systems are instead hardcoded and scattered in the codebase done by those. In early stage startups this is a death kneel.
specialist 5y ago
> I detest it so much that sometimes it makes me wonder if I even want to continue in the programming space 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 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/0201708531/ 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.
jen20 5y ago
I’ll bite: your team may say they are doing “domain driven design” but given from the description that they are not, you could just as well claim to be training alligators and be as correct. However, you _are_ correct to say that DDD has a very limited use - as does the domain model pattern itself. Martin Fowler even calls this out in Patterns of Enterprise Application Architecture, imploring that it is necessary only when there are “complex and ever-changing business rules”. Most business systems should be multi-player Access databases, and instead have “a few sums and not-null checks”, thus should not use a domain model, thus should not use a technique aimed at designing and validating a domain model. Honestly, I’d find a new job.
jcelerier 5y ago
> Don't get me wrong, DDD has meaning and purpose, but some companies are applying it as a badge to be obtained That's the issue. If they weren't doing with DDD they would be doing the exact same thing with whatever the CEO read in Gartner instead anyways.
pjmorris 5y ago
> instead of pondering the question, do you really need to rewrite everything following DDD? Anecdotal: I chatted with Eric Evans, author of the DDD book, at a conference once, and he stressed that DDD was only appropriate for certain parts of the system that called for it. I think he'd be as frustrated as you are by the situation you describe.
corpMaverick 5y ago
Parent poster also mentions in another post that they are also using Microservices. I can see how excessive detail division into Microservices can create a nightmare. I have seen it over and over. We need better guidance on how to breakdown services and how much. Erik Evans touches on this https://www.youtube.com/watch?v=sFCgXH7DwxM https://www.youtube.com/watch?v=sFCgXH7DwxM but I still think he is to shy on giving advice. Microservices are valuable because they allow your team to work autonomously. So you you should roughly have one Microservice per team. It is not a hard rule at all, but it can help to see if your microservices are too granular. That is the number of Microservices should be about 5 to 7 times larger than the number of developers. If you have less than 2 developers per Microservice, you are probably creating a maintenance nightmare.
sigzero 5y ago
I've been in a similar situation so I hear you. It is so mentally draining.
ouro 5y ago
If you are doing CRUD in DDD ... "You are doing it wrong"

macando 5y ago

> it have been divided in more that 25 files that hold 3 or 4 lines of code at most, with so many abstraction layers that it's impossible for the best of us to follow in one go. When you put engineers in charge you get overengineering and when you put managers you get underengineering. Is there a way out?

oscarcp 5y ago
At the moment, there's no way out, plannign stipulates that all our microservices must be rewritten to accomodate this super abstract DDD design (and youy're right, it was an engineer who created our current layout)
deleted 5y ago
[deleted]
tragomaskhalos 5y ago
This is so true, and has been forever. In the early 90s I worked on a system where you couldn't just write structs, rather you had to submit their definition to a guy who entered the details into a database, and there was a daily run to generate the C header files from that database. To this day I'm convinced the only reason it was done this way was that it could be done this way.
- macando 5y ago
  It's an over-reliance on ceremony. On some days I think it's a character trait.
- lgvld 5y ago
  Ouch! Crazy ;-)
deleted 5y ago
[deleted]
mytailorisrich 5y ago
> When you put engineers in charge you get overengineering This means you picked the wrong engineers. An engineer's job and skill is to be able to make this sort of call. The same goes with managers or any other role. So the way out is always to carefully select experienced, competent, no nonsense people.
andi999 5y ago
Getting experienced senior engineers, probably they have seen both; and in the best case they have worked on a middle ground project so they experienced how to do it and how not to do it.
- macando 5y ago
  Experienced and exposed to areas outside their main expertise so they are well rounded and pragmatic.
- moonchrome 5y ago
  I think you need to have a few of those "I've use this pattern and had to stay up 24 hours to meet a deadline because shit was way too complicated for the delivered value" to instil a healthy fear of overcomplicating solutions. I've worked with developers with 5+ years of experience that haven't went trough that (either corporate culture allowed them to deliver minimum value in 5 days or jumping projects before it gets to the WTF stage of complexity). It's hard to learn if you never get burned.
rapnie 5y ago
> When you put engineers in charge you get overengineering and when you put managers you get underengineering. Is there a way out? The whole idea is to bring them together "in the same room" and allow common understanding of the domain so they stay on the same page throughout the project. Then they'll do each what they are best at (managers whip up glossy slides, and devs crank out reams of code ;)

NicoJuicy 5y ago

If it's just crud. Create a minimal API that handles it to show the difference. Which programming language? There was some work shown in .net recently

oscarcp 5y ago
Python, FastAPI... so you can imagine how something as simple as a CRUD becomes quickly impossible to manage as soon as you ignore everything and start creating repositories, queries, use cases, etc. for a single endpoint. I agree with you that a minimal implementation should handle it but... someone had wet dreams with DDD and everything has to be DDD now :)
- NicoJuicy 5y ago
  And for something like "translations crud" this shouldn't be required ( which service needs to be updated from a translation update?). Perhaps that's a perfect example to implement it and push it. ( depends on how far you're willing to go and push back against who) Look for a fancy name to describe the "pattern" could help.

ToJans 5y ago

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, without any added benefit.) You see this a lot when people read some stuff about DDD, and they start experimenting with the technical/tactical patterns, because this is the aspect that makes most sense to a technical audience. In reality the tactical/technical DDD patterns should only be applied in the core part of your business (i.e. the thing that gives you a strategic advantage over your competitors.), because that typically needs to change a lot, so having a common language/model with the business tends to be worth the extra upkeep required when opting for more flexible models. Identifying what the core part is of your business (most likely it's not authentication, billing, invoicing, content management, ...) is one of the more important (and most difficult) aspects of DDD.

oscarcp 5y ago
> 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, without any added benefit.) Exactly :)
y4mi 5y ago
> In reality the tactical/technical DDD patterns should only be applied in the core part of your business [...] I cannot imagine anything where it would make sense unless you're implementing an actual framework such as Spring in javaland. And at that point I'd say you're wasting effort and just using spring boot should be preferable. It does make sense with these super low level frameworks though, but which corporation makes them in-house at this point?
- ToJans 5y ago
  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 are not describing the actual reasoning behind the change. For DDD, it makes sense to figure out why exactly you are doing the things you do, and model these explicitly in your systems for those parts that matter. The stereo-typical example for this is an address change: if you model this as an "AddressUpdated", you might as well use CRUD, as this does not specify the intent of the change. You could change an address because it contained a typo, but you can also change it because someone moved. These might lead to different outcomes, so in DDD you would typically model these as "AddressTypoCorrected" and "ContactMoved". There are other fine-grained aspects, for example the need of an identity for an object: physical money is considered a value object (so it has no specific ID per instance) in almost all contexts, unless you are the national bank: all of a sudden the identity (serial number of the bill) does matter, so the same "thing" might have different "models" within different parts of the business. Other examples might be value objects for specific areas, for example weight. Typically weight starts out as a number, and all of a sudden there might be a need to add a precision, mark it as an estimate, or have it "unknown". In order to avoid if-statements all over the code, you construct a "weight value object" that properly manages all of these peculiarities in a single place (i.e. what's the result of an estimate+undefined etc.)

goto11 5y ago

Developers will destroy everything good! DDD has some great ideas about how to model things and talk about things. But it is not a concrete architecture prescribing a particular number of layers or lines of code.

JackFr 5y ago
I read a preprint of Eric Evans book before it came out, and then bought a copy when it got published. As someone who had been in the industry 6-7 years at that point, it really resonated - he was describing modes of success and failure I had seen but didn’t really have names for. Much of the usefulness of the book was just to put names on these things. What has happened to ‘DDD’ in the meantime surprised me. It never occurred to me from the original book that a methodology of strict practices could emerge from it. To me that wasn’t the sense if it at all.

pydry 5y ago

I noticed something similar. A minimal PR to introduce DDD on our code base ballooned the codebase by something like 1,000 lines, smattered all over the code base. I think it would have ballooned it by about 12-15,000 in total in the end if we'd used it everywhere. That would have been fertile breeding ground for bugs. The ideas made sense on logically complex code that required frequent refactoring, but the strict separation between all the different layers simply led to a lot of code in most instance. Far too much. We also couldnt agree on where the limits of the bounded contexts really lay. Most documentation on this issue is a mere handwave saying "you figure it out" or "it'll become clear when you do these exercises with the business" (it didnt), which is odd given how vitally important it is and how damaging it is to bound the wrong things.

dm3 5y ago
> We also couldnt agree on where the limits of the bounded contexts really lay. Most documentation on this issue is a mere handwave saying "you figure it out" or "it'll become clear when you do these exercises with the business" (it didnt), which is odd given how vitally important it is and how damaging it is to bound the wrong things. This is the hardest part of software design. No wonder there are no clear cut rules on how to do it. You have to be both a domain and implementation expert to get the boundaries right on the first try.
- pydry 5y ago
  Yeah, it is tricky. I've rewritten many a code base because I drew the original boundaries in the wrong place and their logical locations only became clear in retrospect. I'm not so convinced that it's something you can get just by better communicating with "the business" either. This is partly what infuriated me so about the extreme amount of code required to follow DDD patterns - 3-4x the amount of code means 3-4x the cost of that rewrite if you get the boundary wrong.
  - dm3 5y ago
    I find the original tactical DDD patterns as useful as the gang-of-four OOP patterns these days. Modern languages made the latter irrelevant. Modern DDD practice emphasizes getting the strategic aspects of DDD right: language and boundaries. Doesn't matter if your code has a type named `Aggregate` in it. Matters if you get your consistency boundaries right. > I'm not so convinced that it's something you can get just by better communicating with "the business" either. I don't have a good answer for this. I personally try to keep my modules small so that there's not more than a ~week worth of stuff to redo if understanding of business (or business itself) changes. I often fail too.

blowski 5y ago

I call this “domain driven design driven design”.

ajuc 5y ago

I signed for a course on DDD thinking it will be about Data-Driven Design. It was about Domain-Driven Design and it's like the exact opposite. Data-DD is focus on data and keep it simple. Domain-DD is another one of these architecture astronauts fads where you introduce new abstractions and then spend most of the time wondering whether penguin is a bird or a fish for the purpose of your application.

rapnie 5y ago
> Domain-DD is another one of these architecture astronauts fads where you introduce new abstractions Reading this I guess you followed the wrong course. One that shoved you Tactical Patterns down the throat without explaining well-enough why you should use them. DDD in the core is not about architecture, but about *common understanding* of the domain, *before* you start coding and hacking on a particular architecture. The domain understanding should help you make appropriate architecture decisions, but in now way dictate what architecture designs to use.
rewma 5y ago
> Domain-DD is another one of these architecture astronauts fads where you introduce new abstractions and then spend most of the time wondering whether penguin is a bird or a fish for the purpose of your application. That doesn't sound right. Domain-driven design is just a technique to design a data model that fits your application domain, and designs the whole application around that data model. To put it differently, with DDD first you define a data structures, and afterwards the application is just operators over said data structure. The only reason why in DDD you would care about whether "a penguin is a fish or a bird" is if your businesses required handling fishes or birds in fundamentally different and incompatible ways, which would require you to write special purpose code that crossed all layers. It sounds like you've been experiencing a kind of analysis paralysis with the DDD tag.

AndrewSChapman 5y ago

DDD doesn't prescribe any structure really, other than saying you should separate out different contexts and use unified terminology throughout the business, which I don't think anyone would argue against. Are you talking about design patterns by any chance? Maybe things like repositories, adapters, small and focused service classes and the like?

bamboozled 5y ago
If it’s really that simple, why are do bible sized books written on the topic ? Why does it even need a name if it’s just common sense ?
- qaq 5y ago
  Cause consultants need to make $.
- AndrewSChapman 5y ago
  Don't get me wrong, I'm no DDD expert by any stretch. I think the main topic and real difficultly of DDD is figuring out specifically where and how to separate out different contexts (the so-called 'bounded context' in DDD parlance). Creating microservices is a good example. Where should the responsibility for a single microservice start and finish? What might the implications for scalability and extensibility be? What does this mean for data storage? What data will be shared or replicated between microservices and how will this be done? Answering these kinds of questions is hard and has big implications for your teams and for your business.
  - pydry 5y ago
    ^^ 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.
    - 5y ago

HelloNurse 5y ago

In a typical pattern of buzzword adoption, your horrible architecture isn't DDD just because someone calls it so; it's just bad design. In particular, pulverized source files and excessive abstraction layers are characteristic symptoms of dogmatic, value-oblivious impractical design: quite the opposite of thinking hard about a meaningful domain model in order to use it as a shared language.

orthoxerox 5y ago
Exactly like agile, which has morphed into following the rules of the latest Agile Framework.

deleted 5y ago

[deleted]

davedx 5y ago

My experience too. “No silver bullet” is correct. DDD has some value but the cargo culting of it gets pretty ridiculous in some places.

malka 5y ago

Is this your project ? https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

ChicagoDave 5y ago

DDD principals should only be applied to reduce complexity. If the problem space is really just crud applications, DDD modeling or engineering is a waste of time and money. But here’s where you have to be careful. It’s still useful to go through things like Event Storming and modeling domains to understand the problem space before deciding that basic crud is good enough.

lievendoclo 5y ago
I've been coding for over 15 years now and everytime someone says "Nah, we only need CRUD", they end up eating their words a couple of months down the line. The net result: domain logic all over the place. People tend to think that applying DDD infers a tremendous overhead in the code. That doesn't have to be the case. However, some tend to go overboard and that's when I can understand the frustration.
- JackFr 5y ago
  Quick-and-dirty is always dirty and rarely quick.

mathiasverraes 5y ago

I'm sorry you're having that experience. DDD is specifically aimed at tackling complexity, as it says on the cover. Part of the problem is that complexity is relative to the observer, how experienced they are in that particular domain, etc. Good abstractions make complexity manageable, bad ones create more complexity. And that's another problem: a domain might be quite straightforward but bad explanations, missing information, bad abstractions, etc can make it seem more complex. Your colleagues need to remember that DDD is supposed to be applied pragmatically. If the structure causes more navigation work than needed, simplify it. If the problem could be solved with a simple CRUD system, do that. If most of the problem is CRUD, but there's one particularly complex bit that changes a lot and requires a lot of flexibility, isolate that part, so that the simple and complex parts can have a simple integration, don't leak into each other, and can evolve at their own speeds.

rewma 5y ago
> I'm sorry you're having that experience. DDD is specifically aimed at tackling complexity, as it says on the cover. Part of the problem is that complexity is relative to the observer, how experienced they are in that particular domain, etc. I'd say part of the problem is that DDD critics conflate DDD with overly complex, enterprisey models that don't match their personal preferences on the acceptable tradeoffs between complexity and correctness. As DDD comes up sounding like too much work to implement too much complexity that brings too little value, they flag it as a concern. What I believe is missing from this discussion is the scenario where DDD practices are not followed and consequently teams are forced to iterate and reimplements projects or parts of it just to fit requirements that emerged because some aspects of the domain model weren't looked into. Design by accretion is largely accepted, as is technical debt, but they do have a cost.
- oscarcp 5y ago
  You make quite the point here. That is the advantage I see for DDD; you have dependency on service that may change, DDD will make your life easier when switching, otherwise there will be weeks of rewriting code. And what happens during transition times (thinking about CRM for example) where you have to keep connected to both systems?. This said, in my situation it's like trying to kill flies with a muon cannon (fyi. this gun is fictional and it's exaggerated to drive the point), it's cool'n's*it but the same could have been done with a newspaper or your hand. To maintain the muon cannon you need the entire Fermilab team, your hand... well, it's your hand. Apologies for the exaggeration, can't avoid it :D

afurculita 5y ago

You don't use DDD at your current company. Naming it DDD doesn't make it DDD.

ratww 5y ago
That's the "No True Yorkshireman" fallacy. In my experience it's extremely safe to assume that, even with the best intentions, DDD code can become stupid big balls of mud.

nathias 5y ago

This is exactly the state of a project I'm working at, but without DDD and with microservices instead. It is probably more of a general problem of complexity growth that happens when anything goes wrong with architecture and isn't addressed properly not just a consequence of bad DDD.

sweezyjeezy 5y ago

> 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.

mnsc 5y ago
Ok, so in practice you are saying that no good programming paradigm exists. Where do we go from there?
- sweezyjeezy 5y ago
  I agree no paradigm is particularly great for beginners - OOP leads to junior devs separating their code prematurely/inaccurately, writing horrendous inheritance trees etc., functional programming can lead to some really opaque code that feels like you're trying to solve a puzzle when reading it. I do think good principles exist however: - try to write code that can be easily unit tested - composition over inheritance - immutable over mutable + avoid side effects - avoid recursion unless your data is recursive etc. etc.
- pydry 5y ago
  Certainly no good general purpose programming paradigm exists. Nor will it. The more general purpose it purports to be the vaguer and more misapplied it will end up being. DDD could be a lot better as a movement if it tried to limit its scope a bit.
- shados 5y ago
  Wait until the market stabilizes and new dev don't outnumber more senior ones 10:1. 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.
- 5y ago

Jenk 5y ago

Much like most things engineers bitch about, the tool isn't to blame here (as you say yourself) - it's the wrong tool for the wrong job. There's nothing about DDD that says you can't make a simple CRUD API, if that's all that is required. DDD's principle value is one of ubiquity (sold as "Ubiquitous Language" but I posit that "Ubiquity" is more accurate) - does your code do what the organisation does, and vice versa? Not just using the same terminology, but using the same workflow. Now if what the organisation does is basic stuff, then your code should be basic, too. If there is an asymmetry between what the org and code do.. there's pain.

bjornsing 5y ago

> more that 25 files that hold 3 or 4 lines of code at most That sounds kind of annoying, but not very hard to understand.

tenaciousDaniel 5y ago

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-to-understand principles, and I've never understood why the whole DDD space is taken up by this insanely complicated terminology and theory. It's so off-putting.

endymi0n 5y ago
This is exactly spot on and my go-to approach as well. I always thought myself of a huge fan of DDD, simply because I think it makes so much sense to discuss the architecture directly with the stakeholders until everyone technical and nontechnical alike really agrees about the existence, relation and constraints of entities: By using common, ubiquitous language and just giving the same things the same consistent, common-sense names while giving different things different names. 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.
- ratww 5y ago
  Yep, exact same experience. I also had the unfortunate experience of working with some die-hards who believe DDD dictates that "the code and only the code should reflect the business requirements 1:1", with emphasis on the "only". Which means that things that are often configurable in other systems are instead hardcoded and scattered in the codebase done by those. In early stage startups this is a death kneel.

specialist 5y ago

> I detest it so much that sometimes it makes me wonder if I even want to continue in the programming space 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 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/0201708531/ 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.

jen20 5y ago

I’ll bite: your team may say they are doing “domain driven design” but given from the description that they are not, you could just as well claim to be training alligators and be as correct. However, you _are_ correct to say that DDD has a very limited use - as does the domain model pattern itself. Martin Fowler even calls this out in Patterns of Enterprise Application Architecture, imploring that it is necessary only when there are “complex and ever-changing business rules”. Most business systems should be multi-player Access databases, and instead have “a few sums and not-null checks”, thus should not use a domain model, thus should not use a technique aimed at designing and validating a domain model. Honestly, I’d find a new job.

jcelerier 5y ago

> Don't get me wrong, DDD has meaning and purpose, but some companies are applying it as a badge to be obtained That's the issue. If they weren't doing with DDD they would be doing the exact same thing with whatever the CEO read in Gartner instead anyways.

pjmorris 5y ago

> instead of pondering the question, do you really need to rewrite everything following DDD? Anecdotal: I chatted with Eric Evans, author of the DDD book, at a conference once, and he stressed that DDD was only appropriate for certain parts of the system that called for it. I think he'd be as frustrated as you are by the situation you describe.

corpMaverick 5y ago

Parent poster also mentions in another post that they are also using Microservices. I can see how excessive detail division into Microservices can create a nightmare. I have seen it over and over. We need better guidance on how to breakdown services and how much. Erik Evans touches on this https://www.youtube.com/watch?v=sFCgXH7DwxM https://www.youtube.com/watch?v=sFCgXH7DwxM but I still think he is to shy on giving advice. Microservices are valuable because they allow your team to work autonomously. So you you should roughly have one Microservice per team. It is not a hard rule at all, but it can help to see if your microservices are too granular. That is the number of Microservices should be about 5 to 7 times larger than the number of developers. If you have less than 2 developers per Microservice, you are probably creating a maintenance nightmare.

sigzero 5y ago

I've been in a similar situation so I hear you. It is so mentally draining.

ouro 5y ago

If you are doing CRUD in DDD ... "You are doing it wrong"