4 ms·

Haven’t read this one, but have read a few - “Domain Driven Design” (by Eric Evans) was the most influential for me.

by yashap 2y ago

jojohohanon 2y ago
I am very interested in learning more / honing my design skills, But Like everyone else my time is extremely limited. Could you say a few words about DDD stood out for you and what other books you might compare it to?
- sbayeta 2y ago
  (Not gp) I read this book more than a decade ago, when I was very inexperienced. The thing I remember the most, and I think the most valuable to me, is the idea of defining a shared domain language with the business domain experts, with a clearly defined meaning for each concept identified. For instance, what a "frozen" account exactly means, what's the difference with a "blocked" account. These are arbitrary, but must be shared among all the participants. This enables very precise and clear communication.
  - darkerside 2y ago
    I think that's the core idea. The layer on top the idea that that domain language should be expressed in an isolated core layer of your code. Here lies all your business logic. On top of that, you build application layers to adapt it as necessary to interact with the outside world, through things like web pages, emails, etc. as well as infrastructure layers to talk to your database, etc.
  - zeroCalories 2y ago
    At my job we have a shared glossary and data model that we use with business people, but do you really need a whole book on that?
    - jameshart 2y ago
      DDD is about a lot more than just defining what it calls ‘ubiquitous language’. It helps you figure out how to constrain which concerns of the language used in one domain need to affect how other domains think about those things - through a model it calls ‘bounded contexts’. Like, in your fraud prevention context, ‘frozen accounts’ might have all sorts of nuances - there might be a legal freeze or a collections freeze on the account, with different consequences; outside the domain, though, the common concept of ‘frozen’ is all that’s needed. DDD gives you some tools for thinking about how to break your overall business down into bounded contexts that usefully encapsulate complexity, and define the relationships between those domains so you can manage the way abstractions leak between them. No silver bullet, of course, but, like most architectural frameworks, some useful names for concepts that give you the metavocabulary for talking about how to talk about your software systems. This brief chapter from the O’Reilly Learning DDD book gives a good flavor of some of the value of the concepts it introduces: https://www.oreilly.com/library/view/learning-domain-driven-design/9781098100124/ch04.html https://www.oreilly.com/library/view/learning-domain-driven-...
      - zeroCalories 2y ago
        Thanks for the explanation, I'll take a deeper look.
    - aspenmayer 2y ago
      In highly regulated industries like banking or other highly-secure environments, it’s a gradient between an internal wiki or FAQs etc, to what you have as an example of something more expansive and explicit, to an entire book, to an entire department or business unit for more important concepts that may vary between jurisdictions or be less explicitly defined, but no less important or impactful to the running of the business or group.
- crdrost 2y ago
  Not the person you're asking but thought I would chip in. Domain Driven Design has a lot of good ideas, but then I consistently see them misrepresented by others who seem to half-understand it? Probably the clearest example is the idea of a “bounded context.” You will find microservice folks for example who say you should decompose such that each microservice is one bounded context and vice versa, but then when they actually decompose a system there's like one microservice per entity kind (in SQL, this is a relation or table, so in a microservice pet-adoption app there would be a cat service, a dog service, a shelter service, an approval service, a user service...). The thing is, Eric Evans is pretty clear about what he means by bounded context, and in my words it is taking Tim Peters’s dictum “Namespaces are one honking great idea—let’s do more of those!” and applying it to business vocabulary. So the idea is that Assembly Designer Jerry on the 3rd floor means X when he says “a project,” but our pipefitter Alice on the shop floor means something different when she says “a project,” and whenever she hears Jerry talking about a project she is mentally translating that to the word “contract” which has an analogous meaning in her vocabulary. And DDD is saying we should carefully create a namespace boundary so that we can talk about “pipefitting projects” and “pipefitting contracts” and “assembly-design projects” and then have maybe a one-to-one relationship between pipefitting contracts and assembly-design projects. Eric Evans wants this so that when a pipefitter comes to us and tells us that there's a problem with “the project,” we immediately look at the pipefitter project and not the assembly-design project. He really hates that wasted effort that comes from the program not being implemented in vocabulary that closely matches the language of the business. So if the microservices folks actually had internalized Eric's point, then they would carve their microservices not around kinds of entities, but rather archetypes of users. So for the pet adoption center you would actually start with a shelter admin service and a prospective adopter service and a background checker service, assuming those are the three categories of people who need to interact with the pet adoption process. Or like for a college bursar's office you would decompose into a teacher service, student service, admin service, accountant service, financial aid worker service, person who reminds you that you haven't paid your bills yet service. So I thought it was a really good read, that's actually a really interesting perspective, right? But I don't think the ideas inside are communicated with enough clarity that I can bond with others who have read this book. It is kind of strange in that regard.
- doctor_eval 2y ago
  I think DDD is a great book but like many of these kinds of things, I also think it's one of those books that has a couple of chapters of good ideas and then a dozen chapters of filler. That said, ideas like ubiquitous language and bounded contexts are extraordinarily powerful, and definitely sharpened my own observations, so despite the filler, all in all I'd say it's one of the keystone books on software design and definitely worth reading. Another thing that DDD talks about, and is relevant to this, is that design and implementation are two sides of the same coin. In "Just Enough", Fairbanks says, "Every architect I have met wishes that all developers understood architecture". Well, I am not kidding when I say that I wish every architect I've ever met understood software. A lack of understanding of the technical constraints of computing is just as likely to lead to failure as misunderstanding the business constraints. They are both critical to success, and these people should be working and learning from each other, rather than operating in a hierarchy. To that point, one of the most influential things I've ever read was Code as Design: https://www.developerdotstar.com/mag/articles/reeves_design_main.html https://www.developerdotstar.com/mag/articles/reeves_design_... Since it's a series of essays, it has all the detail and none of the filler.
- cpeterso 2y ago
  “Domain-Driven Design Quickly” is a nice introduction to DDD concepts and patterns. The book is available free online. Much more accessible than Eric Evans’ (great but dense!) book. https://www.infoq.com/minibooks/domain-driven-design-quickly/ https://www.infoq.com/minibooks/domain-driven-design-quickly...
globular-toast 2y ago
One of my favourite books. Some people seem to prefer "Implementing Domain-Driven Design" by Vaughn Vernon. I have both on my shelf but I've never been able to read much of the latter. Clean Architecture by Robert C. Martin has a lot of the same stuff distilled into more general rules that would apply to all software, not just "business" software. It's a good book but overall I prefer DDD.

Haven’t read this one, but have read a few - “Domain Driven Design” (by Eric Evans) was the most influential for me.

by yashap 2y ago

Haven’t read this one, but have read a few - “Domain Driven Design” (by Eric Evans) was the most influential for me.

I am very interested in learning more / honing my design skills, But Like everyone else my time is extremely limited. Could you say a few words about DDD stood out for you and what other books you might compare it to?

sbayeta 2y ago
(Not gp) I read this book more than a decade ago, when I was very inexperienced. The thing I remember the most, and I think the most valuable to me, is the idea of defining a shared domain language with the business domain experts, with a clearly defined meaning for each concept identified. For instance, what a "frozen" account exactly means, what's the difference with a "blocked" account. These are arbitrary, but must be shared among all the participants. This enables very precise and clear communication.
- darkerside 2y ago
  I think that's the core idea. The layer on top the idea that that domain language should be expressed in an isolated core layer of your code. Here lies all your business logic. On top of that, you build application layers to adapt it as necessary to interact with the outside world, through things like web pages, emails, etc. as well as infrastructure layers to talk to your database, etc.
- zeroCalories 2y ago
  At my job we have a shared glossary and data model that we use with business people, but do you really need a whole book on that?
  - jameshart 2y ago
    DDD is about a lot more than just defining what it calls ‘ubiquitous language’. It helps you figure out how to constrain which concerns of the language used in one domain need to affect how other domains think about those things - through a model it calls ‘bounded contexts’. Like, in your fraud prevention context, ‘frozen accounts’ might have all sorts of nuances - there might be a legal freeze or a collections freeze on the account, with different consequences; outside the domain, though, the common concept of ‘frozen’ is all that’s needed. DDD gives you some tools for thinking about how to break your overall business down into bounded contexts that usefully encapsulate complexity, and define the relationships between those domains so you can manage the way abstractions leak between them. No silver bullet, of course, but, like most architectural frameworks, some useful names for concepts that give you the metavocabulary for talking about how to talk about your software systems. This brief chapter from the O’Reilly Learning DDD book gives a good flavor of some of the value of the concepts it introduces: https://www.oreilly.com/library/view/learning-domain-driven-design/9781098100124/ch04.html https://www.oreilly.com/library/view/learning-domain-driven-...
    - zeroCalories 2y ago
      Thanks for the explanation, I'll take a deeper look.
  - aspenmayer 2y ago
    In highly regulated industries like banking or other highly-secure environments, it’s a gradient between an internal wiki or FAQs etc, to what you have as an example of something more expansive and explicit, to an entire book, to an entire department or business unit for more important concepts that may vary between jurisdictions or be less explicitly defined, but no less important or impactful to the running of the business or group.
crdrost 2y ago
Not the person you're asking but thought I would chip in. Domain Driven Design has a lot of good ideas, but then I consistently see them misrepresented by others who seem to half-understand it? Probably the clearest example is the idea of a “bounded context.” You will find microservice folks for example who say you should decompose such that each microservice is one bounded context and vice versa, but then when they actually decompose a system there's like one microservice per entity kind (in SQL, this is a relation or table, so in a microservice pet-adoption app there would be a cat service, a dog service, a shelter service, an approval service, a user service...). The thing is, Eric Evans is pretty clear about what he means by bounded context, and in my words it is taking Tim Peters’s dictum “Namespaces are one honking great idea—let’s do more of those!” and applying it to business vocabulary. So the idea is that Assembly Designer Jerry on the 3rd floor means X when he says “a project,” but our pipefitter Alice on the shop floor means something different when she says “a project,” and whenever she hears Jerry talking about a project she is mentally translating that to the word “contract” which has an analogous meaning in her vocabulary. And DDD is saying we should carefully create a namespace boundary so that we can talk about “pipefitting projects” and “pipefitting contracts” and “assembly-design projects” and then have maybe a one-to-one relationship between pipefitting contracts and assembly-design projects. Eric Evans wants this so that when a pipefitter comes to us and tells us that there's a problem with “the project,” we immediately look at the pipefitter project and not the assembly-design project. He really hates that wasted effort that comes from the program not being implemented in vocabulary that closely matches the language of the business. So if the microservices folks actually had internalized Eric's point, then they would carve their microservices not around kinds of entities, but rather archetypes of users. So for the pet adoption center you would actually start with a shelter admin service and a prospective adopter service and a background checker service, assuming those are the three categories of people who need to interact with the pet adoption process. Or like for a college bursar's office you would decompose into a teacher service, student service, admin service, accountant service, financial aid worker service, person who reminds you that you haven't paid your bills yet service. So I thought it was a really good read, that's actually a really interesting perspective, right? But I don't think the ideas inside are communicated with enough clarity that I can bond with others who have read this book. It is kind of strange in that regard.
doctor_eval 2y ago
I think DDD is a great book but like many of these kinds of things, I also think it's one of those books that has a couple of chapters of good ideas and then a dozen chapters of filler. That said, ideas like ubiquitous language and bounded contexts are extraordinarily powerful, and definitely sharpened my own observations, so despite the filler, all in all I'd say it's one of the keystone books on software design and definitely worth reading. Another thing that DDD talks about, and is relevant to this, is that design and implementation are two sides of the same coin. In "Just Enough", Fairbanks says, "Every architect I have met wishes that all developers understood architecture". Well, I am not kidding when I say that I wish every architect I've ever met understood software. A lack of understanding of the technical constraints of computing is just as likely to lead to failure as misunderstanding the business constraints. They are both critical to success, and these people should be working and learning from each other, rather than operating in a hierarchy. To that point, one of the most influential things I've ever read was Code as Design: https://www.developerdotstar.com/mag/articles/reeves_design_main.html https://www.developerdotstar.com/mag/articles/reeves_design_... Since it's a series of essays, it has all the detail and none of the filler.
cpeterso 2y ago
“Domain-Driven Design Quickly” is a nice introduction to DDD concepts and patterns. The book is available free online. Much more accessible than Eric Evans’ (great but dense!) book. https://www.infoq.com/minibooks/domain-driven-design-quickly/ https://www.infoq.com/minibooks/domain-driven-design-quickly...

globular-toast 2y ago

One of my favourite books. Some people seem to prefer "Implementing Domain-Driven Design" by Vaughn Vernon. I have both on my shelf but I've never been able to read much of the latter. Clean Architecture by Robert C. Martin has a lot of the same stuff distilled into more general rules that would apply to all software, not just "business" software. It's a good book but overall I prefer DDD.