4 ms·

DDD doesn't prescribe any structure really, other than saying you should separate out different contexts and use unified terminology throughout the business, wh

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.
    - rapnie 5y ago
      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 of 'doing DDD'.
      - pydry 5y ago
        >Whether you use factories or not is a much lower-level technical decision far removed from the essence and rationale of 'doing DDD'. 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-design-and-the-role-of-the-factory-class 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.
        rapnie 5y ago
        That SO article if from '09 when 'big OOP' was all the hype. Hyping things to bigger proportions than they should be are a problem in IT. We just saw it for 'Microservices', for instance. These hypes serve to overpromise what you'll get, and sow confusion for years to come. In that regard I hope that DDD will not climb the hype cycle again, and we'll stay calm and just use what works. I think most important to realize that DDD is just another tool in your toolbox, and can be used alongside all / most of the other tools you already use. Event storming can be a nice way to quickly kick off the elaboration process, should the method appeal to you.
- nvarsj 5y ago
  Any engineering methodology that requires 500+ pages to explain should be hard avoided. The size of those DDD books always made me run away. Good engineering should always come back to KISS. Abstract only when it helps reduce complexity.
- konschubert 5y ago
  People write books that could be blog posts all the time. Most non-fiction literature is like that.
- JackFr 5y ago
  > If it’s really that simple, why are do bible sized books written on the topic ? Money.

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.
  - rapnie 5y ago
    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 of 'doing DDD'.
    - pydry 5y ago
      >Whether you use factories or not is a much lower-level technical decision far removed from the essence and rationale of 'doing DDD'. 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-design-and-the-role-of-the-factory-class 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.
      - rapnie 5y ago
        That SO article if from '09 when 'big OOP' was all the hype. Hyping things to bigger proportions than they should be are a problem in IT. We just saw it for 'Microservices', for instance. These hypes serve to overpromise what you'll get, and sow confusion for years to come. In that regard I hope that DDD will not climb the hype cycle again, and we'll stay calm and just use what works. I think most important to realize that DDD is just another tool in your toolbox, and can be used alongside all / most of the other tools you already use. Event storming can be a nice way to quickly kick off the elaboration process, should the method appeal to you.
nvarsj 5y ago
Any engineering methodology that requires 500+ pages to explain should be hard avoided. The size of those DDD books always made me run away. Good engineering should always come back to KISS. Abstract only when it helps reduce complexity.
konschubert 5y ago
People write books that could be blog posts all the time. Most non-fiction literature is like that.
JackFr 5y ago
> If it’s really that simple, why are do bible sized books written on the topic ? Money.