5 ms·

> [Abstraction heavy paradigms] structure the code around the description of the problem domain My experience of Domain-Driven Design has been that it is extre

by dkarl 3y ago

> [Abstraction heavy paradigms] structure the code around the description of the problem domain My experience of Domain-Driven Design has been that it is extremely effective for driving conversations about the domain throughout the product life-cycle, but it produces frustrating codebases that are poorly attuned to the world outside the running process. Domain-Driven Design codebases want to be self-contained universes and treat external systems as details. OO design paradigms in general seem to have little respect for messages exchanged with external systems. This wasn't true back when JavaBeans and object databases other distributed object systems were expected to take over the world, but the failure of those technologies shrank the OO world from distributed systems to isolated programs. These days, the messages exchanged with external systems are just data, without behavior. The marriage of data and behavior can only exist inside a single process. So object-oriented design turned inward and concentrated on the creation of rich inner worlds. I think this is backwards, or at least incomplete. As Rich Hickey says, effective programs need to be situated in the real world. They are not ethereal abstract models. They have concrete functions, inputs and outputs. Having rich internal abstractions that mimic some aspects of reality is a means to an end, entirely subordinate to the purpose of executing interactions with other computing systems. Data-driven design embraces this reality. By treating data as essential, and behavior as something to be added when it is needed, it allows inputs and outputs to be first-class citizens. > The data-oriented design approach doesn't build the real-world problem into the code. This could be seen as a failing of the data-oriented approach by veteran object-oriented developers, as examples of the success of object-oriented design come from being able to bring the human concepts to the machine I think this perfectly sums up the confusion that OO modeling creates. You use code to write programs, or services, or cloud functions, things like that. The real-world problem that a program, service, or cloud function solves is interacting in a certain way with other programs, services, cloud functions. The real-world problems that OO modeling paradigms want you to focus on are the domain problems. This is vitally important for design products, systems of programs that solve real human problems. If you are designing a system for managing medical records in a hospital, you need to model doctors, nurses, patients, labs, radiology images, patient stays, all those real-world things. However, when you are designing a piece of software to do one thing within that medical records system, the "real-world problem" your code is solving is limited to its role within the larger system. Data-oriented design is a natural mental fit for writing programs or services that play a limited part in larger systems, which is always what you are doing when you are writing code. Object-oriented design wants to take on the complexity of the whole real world, which is the right perspective for product design and architecture, not for writing code.

rapnie 3y ago
> My experience of Domain-Driven Design has been that it is extremely effective for driving conversations about the domain throughout the product life-cycle, but it produces frustrating codebases that are poorly attuned to the world outside the running process. The DDD blue book by Eric Evans consists of two parts: Strategic Design and Tactical Patters. Is it accurate to summarize your comment as that the strategic design works very well, but that most of the information out there leads one to then learn about the tactical patterns in a particular OOP contexts, which isn't a universal approach, and in many cases shouldn't be the way to elaborate findings from Strategic Design? Note that searching the web for "DDD" yields mostly OOP-related tactical patterns guidance, and this is why I think many people are so sceptical about DDD. It is the strategic parts where most of the (low-hanging fruit) value is. Other non-OOP 'tactical' guidance, such as functional / functional-reactive / actor-driven, etc. DDD is harder to come by.
- dkarl 3y ago
  In my copy of the blue book, "Strategic Design" is Part IV, and there is no "Tactical Patterns" part or chapter. To be honest, I've only quickly read through Part IV, cherry-picking a couple of concepts, because it concentrates on techniques for dealing with very large domain models and/or very large organizations. I think the good and bad are interleaved together throughout the book. Part I Chapter 2, "Communication and the Use of Language," is the one chapter I wish everybody I work with would read and digest. I think establishing a consistent language about the domain that is shared across functional groups is critical, so the domain terminology used in source code and comments is consistent with the terminology engineers use when talking with product and customer support. Part I Chapter 3 contains the clearest statement of (what I think is) the core error: "Tightly relating the code to an underlying model [which context makes clear is the domain model] gives the code meaning and makes the model relevant." The rest of the book is like that for me, alternating between vigorously nodding my head and yelling "WHY WOULD YOU TELL PEOPLE THAT," sometimes within the same chapter. I suspect overall there's a communication issue with the book, where he focuses entirely on the themes of DDD and only occasionally gives lip service to other aspects of design. For example, when he says that module names and structures should reflect domain concepts, I think, "Yeah, that's really nice to the extent you can accomplish that, but you also want your module names and structures to reflect the logical structure of your program, so somebody can look at it and see how it works." You have these two aspects that should ideally both be legible in the code, but the DDD book doesn't show much respect for competing design priorities. In fact, it often warns against the dangers of being led astray by other design perspectives, such as architectural ones. Like so many other OO methodologies, the overwhelming thrust of the book is that if you attend to what it's teaching you, everything else will take care of itself. A priest once told me, a good priest will tell you when you need a lawyer, a good lawyer will tell you when you need a therapist, a good therapist will tell you when you need a doctor, and a good doctor will tell you when you need a priest. Be careful with an expert who always tells you that their expert perspective is what you need. The DDD book is definitely that kind of expert you have to be careful with.

by dkarl 3y ago

rapnie 3y ago

> My experience of Domain-Driven Design has been that it is extremely effective for driving conversations about the domain throughout the product life-cycle, but it produces frustrating codebases that are poorly attuned to the world outside the running process. The DDD blue book by Eric Evans consists of two parts: Strategic Design and Tactical Patters. Is it accurate to summarize your comment as that the strategic design works very well, but that most of the information out there leads one to then learn about the tactical patterns in a particular OOP contexts, which isn't a universal approach, and in many cases shouldn't be the way to elaborate findings from Strategic Design? Note that searching the web for "DDD" yields mostly OOP-related tactical patterns guidance, and this is why I think many people are so sceptical about DDD. It is the strategic parts where most of the (low-hanging fruit) value is. Other non-OOP 'tactical' guidance, such as functional / functional-reactive / actor-driven, etc. DDD is harder to come by.

dkarl 3y ago
In my copy of the blue book, "Strategic Design" is Part IV, and there is no "Tactical Patterns" part or chapter. To be honest, I've only quickly read through Part IV, cherry-picking a couple of concepts, because it concentrates on techniques for dealing with very large domain models and/or very large organizations. I think the good and bad are interleaved together throughout the book. Part I Chapter 2, "Communication and the Use of Language," is the one chapter I wish everybody I work with would read and digest. I think establishing a consistent language about the domain that is shared across functional groups is critical, so the domain terminology used in source code and comments is consistent with the terminology engineers use when talking with product and customer support. Part I Chapter 3 contains the clearest statement of (what I think is) the core error: "Tightly relating the code to an underlying model [which context makes clear is the domain model] gives the code meaning and makes the model relevant." The rest of the book is like that for me, alternating between vigorously nodding my head and yelling "WHY WOULD YOU TELL PEOPLE THAT," sometimes within the same chapter. I suspect overall there's a communication issue with the book, where he focuses entirely on the themes of DDD and only occasionally gives lip service to other aspects of design. For example, when he says that module names and structures should reflect domain concepts, I think, "Yeah, that's really nice to the extent you can accomplish that, but you also want your module names and structures to reflect the logical structure of your program, so somebody can look at it and see how it works." You have these two aspects that should ideally both be legible in the code, but the DDD book doesn't show much respect for competing design priorities. In fact, it often warns against the dangers of being led astray by other design perspectives, such as architectural ones. Like so many other OO methodologies, the overwhelming thrust of the book is that if you attend to what it's teaching you, everything else will take care of itself. A priest once told me, a good priest will tell you when you need a lawyer, a good lawyer will tell you when you need a therapist, a good therapist will tell you when you need a doctor, and a good doctor will tell you when you need a priest. Be careful with an expert who always tells you that their expert perspective is what you need. The DDD book is definitely that kind of expert you have to be careful with.