6 ms·

I thought the DDD hype has died down a bit, but I guess not. Eric Evans (inventor of DDD) has said in recent years that unfortunately once a team is big enough

I thought the DDD hype has died down a bit, but I guess not. Eric Evans (inventor of DDD) has said in recent years that unfortunately once a team is big enough, all the invisible conceptual boundaries between domains blur and disappear. People do NOT have the discipline to do DDD correctly. But do you know what helps? Having physical boundaries you can't cross so easily. Microservices. Or as I call them... just "services". Eric Evans has said that people using microservices may represent the most successful application of DDD's principles, not because people using them were fans or even aware of DDD, but microservices enforce the patterns DDD Evans was describing.

alfonsodev 4y ago
Would you have the quote on that? I'm curious. In my opinion, Microservices is an implementation detail, and the extend to which DDD principles are applied is about people and ownership.
- leidenfrost 4y ago
  > Microservices is an implementation detail It is. But it's a very strong one, where it's harder to blur the boundaries because you're putting your code into a service or another. And that's the advantage. Not because it's easier to apply correctly. But because it's harder to do it badly. And if you do it badly, it will show and the product performance will be a mess.
- moystard 4y ago
  Interested in having the quote as well, and ideally the presentation/keynote/interview that came with it. From my experience, breaking down a monolith without first identifying and isolating its bounded contexts (as in DDD) is a recipe for disaster. With your domains completely entangled in a single codebase, you won't pull only what you want and you will have to bring a lot of undesired code, behaviours and side effects with it. The safest recipe, in my opinion, is to break down your monolith in bounded contexts (or ideally, to have focused on it from the start), so you can better reason and understand the advantages and trade-offs of moving each specific domain and responsibilities out of your unique codebase. I saw often teams being motivated in moving their code out of a legacy codebase because of the huge technical debt, but they were bound to suffer a death of a thousand cuts by just bring the same debt in a new service, and adding network constraints on top.
marginalia_nu 4y ago
> But do you know what helps? Having physical boundaries you can't cross so easily. Microservices. Or as I call them... just "services". Eric Evans has said that people using microservices may represent the most successful application of DDD's principles, not because people using them were fans or even aware of DDD, but microservices enforce the patterns DDD Evans was describing. Sir, your assembly code is so hard to read with all them GOTOs. You should do structured programming, use constructs such as loops to make it easier to follow. Man, your code is so long written like that, you should break it into functions to make it easier to reason about. Dude, you have so many functions it's impossible to make heads or tails of the logic, you should break it into classes to be able to abstract away all of this detail. Bro, you have so many classes I don't even know where to start. You should introduce modules so that it becomes possible to isolate different parts of the design. Dawg, you have so many modules, you ought to break them into small different runtimes communicating via a rest protocol to isolate different parts of the code. Choom, you have so many microservices, you ought to break them into different microclusters to separate the different parts of the API. X'man, you have so many microclusters, you really ought to break them into different miniclouds to spearate the functionality and make it easier to follow. 𐀘𐀐, you have so many miniclouds it's impossible to deal with this code, you really ought to separate it into functional minicloud clusters.
- nopeYouAreWrong 4y ago
  this is a good summary of why I pay zero attention to power point decks and blog posts. there is never a right answer and it's just people masturbating in circles. it's not rocket science, half of the time it's not even computer science. design patterns, at a certain point, become full of themselves.
  - deleted 4y ago
    [deleted]
- Scarblac 4y ago
  It's as I've always said, every function ("unit") should be responsible for a single thing, and it must be developed by an independent company with no knowledge of the other companies involved. Otherwise you just can't do software engineering right.
est 4y ago
> once a team is big enough, all the invisible conceptual boundaries between domains blur and disappear Conway's law: Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
- BulgarianIdiot 4y ago
  Precisely. But this is how it should be. The service is a part of the team, but automating the "mundane things" that people can delegate to machines, instead of doing them manually themselves. This is why, BTW, I'm so dismayed Elon Must fired 85% of Twitter. Now many of their critical services have teams of zero or one developer. Those are basically dead services walking.
  - anon7725 4y ago
    > Precisely. But this is how it should be. The service is a part of the team, but automating the "mundane things" that people can delegate to machines, instead of doing them manually themselves. The organization is often not reflective of what’s actually being achieved. Instead of Catalog, Offer, Order and Shipment you have Alice’s org, Bob’s org and Charlie’s org. If you encode the interfaces between these (impermanent) group boundaries rather than the conceptual boundaries you enter a world of pain. Charlie might own Order and Shipment because Charlie is the warehouse exec and 20 years ago, when only physical items were sold, all of the order-processing computers were located in a cage in the warehouse. Fast forward to today and the cage is gone, and the order processing system handles digital items and services in addition to physical goods. But good old Charlie still owns the Order and Shipment system because they were baked together 20 years ago.
    - theptip 4y ago
      This is true, but I think things like DDD provide an antidote (or at least, some pressure to organize along different dimensions). If you are explicitly talking about business domains and bounded contexts, then you can see areas where the Alice/Bob split is not optimal (typically, lots of team coupling across org boundaries). Without those concepts I think it is easier to justify arbitrary political/territorial org structures. There is no panacea; one can always provide contorted justifications for things. But I think having a framework really helps, and particularly, having one that includes business stakeholders and not just pure technical functions.
goostavos 4y ago
>But do you know what helps? Having physical boundaries you can't cross so easily. Rarely have I disagreed with something more strongly :) If a team lacks the discipline/skill/wherewithal to create good boundaries within a single code base when stakes are at their lowest, they absolutely don't have the skill or discipline to do ahead of time, across N code bases, and with a network in between all of them. Breaking your system apart too early, and when you know the least about it, and with the rationale that doing so will magically stop the problems that a lack of engineering skill creates, has, at least in the small slice of the world I've encountered, resulted in nightmarish levels of complexity (some of which I'm directly responsible for the reasons stated! (whoops!)).
- BulgarianIdiot 4y ago
  You can disagree with it and blame the developers, but the fact is that DDD fails basically every time, unless physical boundaries stop you from failing. It's like saying a good driver won't have an accident on a sharp corner of an icy road, but yet you have a ton of accidents on that corner on an icy road. Facts are facts. Just as it's a fact you can't hope every organization to be staffed by 100% geniuses who never make a mistake. Part of the problem is the platform itself. Most mainstream languages today ALL support shared mutable state. Meaning you can hold a pointer or a handle to something, mutate it, and someone else having the same pointer or handle has it changed under their nose. When you fetch, say, JSON over the network, the party who sent it to you can't change it under your nose either intentionally or accidentally. It's a snapshot of data you own, and you can make decisions on at your own leisure. Sure, the snapshot may get out of date by the time you send your next API request, but this contract is clear and obvious. While the entangled meshes of mutable code in say C, C++, Java, Swift, Python, JS, etc. etc. often make the mess unavoidable. Rust goes to some length to stop this problem, but it's a language that's low-level (by modern standards) and technical, and I don't think anyone uses it for enterprise automation exactly. Another problem are nominal (vs. structural) type systems. Well I don't have to explain, but when you fetch JSON from an API a nominal type won't stop you from reading that data, you care about the structure.
  - hcarvalhoalves 4y ago
theptip 4y ago
Indeed, Uber re-discovered Bounded Contexts not that long ago: https://www.uber.com/blog/microservice-architecture/ https://www.uber.com/blog/microservice-architecture/ (Though only after they felt the pain of thousands of disorganized services.)
JamesBarney 4y ago
Did he elaborate on how big he thought the team needed to be before microservices were required for DDD?
lowbloodsugar 4y ago
No plan survives contact with the enemy. But without a plan, neither will you.

alfonsodev 4y ago

Would you have the quote on that? I'm curious. In my opinion, Microservices is an implementation detail, and the extend to which DDD principles are applied is about people and ownership.

leidenfrost 4y ago
> Microservices is an implementation detail It is. But it's a very strong one, where it's harder to blur the boundaries because you're putting your code into a service or another. And that's the advantage. Not because it's easier to apply correctly. But because it's harder to do it badly. And if you do it badly, it will show and the product performance will be a mess.
moystard 4y ago
Interested in having the quote as well, and ideally the presentation/keynote/interview that came with it. From my experience, breaking down a monolith without first identifying and isolating its bounded contexts (as in DDD) is a recipe for disaster. With your domains completely entangled in a single codebase, you won't pull only what you want and you will have to bring a lot of undesired code, behaviours and side effects with it. The safest recipe, in my opinion, is to break down your monolith in bounded contexts (or ideally, to have focused on it from the start), so you can better reason and understand the advantages and trade-offs of moving each specific domain and responsibilities out of your unique codebase. I saw often teams being motivated in moving their code out of a legacy codebase because of the huge technical debt, but they were bound to suffer a death of a thousand cuts by just bring the same debt in a new service, and adding network constraints on top.

marginalia_nu 4y ago

> But do you know what helps? Having physical boundaries you can't cross so easily. Microservices. Or as I call them... just "services". Eric Evans has said that people using microservices may represent the most successful application of DDD's principles, not because people using them were fans or even aware of DDD, but microservices enforce the patterns DDD Evans was describing. Sir, your assembly code is so hard to read with all them GOTOs. You should do structured programming, use constructs such as loops to make it easier to follow. Man, your code is so long written like that, you should break it into functions to make it easier to reason about. Dude, you have so many functions it's impossible to make heads or tails of the logic, you should break it into classes to be able to abstract away all of this detail. Bro, you have so many classes I don't even know where to start. You should introduce modules so that it becomes possible to isolate different parts of the design. Dawg, you have so many modules, you ought to break them into small different runtimes communicating via a rest protocol to isolate different parts of the code. Choom, you have so many microservices, you ought to break them into different microclusters to separate the different parts of the API. X'man, you have so many microclusters, you really ought to break them into different miniclouds to spearate the functionality and make it easier to follow. 𐀘𐀐, you have so many miniclouds it's impossible to deal with this code, you really ought to separate it into functional minicloud clusters.

nopeYouAreWrong 4y ago
this is a good summary of why I pay zero attention to power point decks and blog posts. there is never a right answer and it's just people masturbating in circles. it's not rocket science, half of the time it's not even computer science. design patterns, at a certain point, become full of themselves.
- deleted 4y ago
  [deleted]
Scarblac 4y ago
It's as I've always said, every function ("unit") should be responsible for a single thing, and it must be developed by an independent company with no knowledge of the other companies involved. Otherwise you just can't do software engineering right.

est 4y ago

> once a team is big enough, all the invisible conceptual boundaries between domains blur and disappear Conway's law: Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

BulgarianIdiot 4y ago
Precisely. But this is how it should be. The service is a part of the team, but automating the "mundane things" that people can delegate to machines, instead of doing them manually themselves. This is why, BTW, I'm so dismayed Elon Must fired 85% of Twitter. Now many of their critical services have teams of zero or one developer. Those are basically dead services walking.
- anon7725 4y ago
  > Precisely. But this is how it should be. The service is a part of the team, but automating the "mundane things" that people can delegate to machines, instead of doing them manually themselves. The organization is often not reflective of what’s actually being achieved. Instead of Catalog, Offer, Order and Shipment you have Alice’s org, Bob’s org and Charlie’s org. If you encode the interfaces between these (impermanent) group boundaries rather than the conceptual boundaries you enter a world of pain. Charlie might own Order and Shipment because Charlie is the warehouse exec and 20 years ago, when only physical items were sold, all of the order-processing computers were located in a cage in the warehouse. Fast forward to today and the cage is gone, and the order processing system handles digital items and services in addition to physical goods. But good old Charlie still owns the Order and Shipment system because they were baked together 20 years ago.
  - theptip 4y ago
    This is true, but I think things like DDD provide an antidote (or at least, some pressure to organize along different dimensions). If you are explicitly talking about business domains and bounded contexts, then you can see areas where the Alice/Bob split is not optimal (typically, lots of team coupling across org boundaries). Without those concepts I think it is easier to justify arbitrary political/territorial org structures. There is no panacea; one can always provide contorted justifications for things. But I think having a framework really helps, and particularly, having one that includes business stakeholders and not just pure technical functions.

goostavos 4y ago

>But do you know what helps? Having physical boundaries you can't cross so easily. Rarely have I disagreed with something more strongly :) If a team lacks the discipline/skill/wherewithal to create good boundaries within a single code base when stakes are at their lowest, they absolutely don't have the skill or discipline to do ahead of time, across N code bases, and with a network in between all of them. Breaking your system apart too early, and when you know the least about it, and with the rationale that doing so will magically stop the problems that a lack of engineering skill creates, has, at least in the small slice of the world I've encountered, resulted in nightmarish levels of complexity (some of which I'm directly responsible for the reasons stated! (whoops!)).

BulgarianIdiot 4y ago
You can disagree with it and blame the developers, but the fact is that DDD fails basically every time, unless physical boundaries stop you from failing. It's like saying a good driver won't have an accident on a sharp corner of an icy road, but yet you have a ton of accidents on that corner on an icy road. Facts are facts. Just as it's a fact you can't hope every organization to be staffed by 100% geniuses who never make a mistake. Part of the problem is the platform itself. Most mainstream languages today ALL support shared mutable state. Meaning you can hold a pointer or a handle to something, mutate it, and someone else having the same pointer or handle has it changed under their nose. When you fetch, say, JSON over the network, the party who sent it to you can't change it under your nose either intentionally or accidentally. It's a snapshot of data you own, and you can make decisions on at your own leisure. Sure, the snapshot may get out of date by the time you send your next API request, but this contract is clear and obvious. While the entangled meshes of mutable code in say C, C++, Java, Swift, Python, JS, etc. etc. often make the mess unavoidable. Rust goes to some length to stop this problem, but it's a language that's low-level (by modern standards) and technical, and I don't think anyone uses it for enterprise automation exactly. Another problem are nominal (vs. structural) type systems. Well I don't have to explain, but when you fetch JSON from an API a nominal type won't stop you from reading that data, you care about the structure.
- hcarvalhoalves 4y ago

theptip 4y ago

Indeed, Uber re-discovered Bounded Contexts not that long ago: https://www.uber.com/blog/microservice-architecture/ https://www.uber.com/blog/microservice-architecture/ (Though only after they felt the pain of thousands of disorganized services.)

JamesBarney 4y ago

Did he elaborate on how big he thought the team needed to be before microservices were required for DDD?

lowbloodsugar 4y ago

No plan survives contact with the enemy. But without a plan, neither will you.