4 ms·

As far as I can tell, the analysis of the problem is completely off base. The author is just trading one set of hyped buzzwords (microservices/k8s/devops) for

by hsn915 5y ago

As far as I can tell, the analysis of the problem is completely off base. The author is just trading one set of hyped buzzwords (microservices/k8s/devops) for another (oop/solid/ddd). It doesn't help when he claims that his approach is proved by science!! There's no approach to software development that has been proven by science. As far as I can tell, the search for the right methodology is part of the problem. Instead of just writing the most sensible and simple code that would work, you have to adhere to some methodology. Object Oriented Programming is not going to solve your maintenance problems and development speed. In my experience, it only makes it worse. As far as I can tell, the author acknowledges that his methodology is not working for a lot of people, but he attributes that to "you're not doing it correctly" which is typical of advocates of OOP/SOLID/etc. But this same excuse can be said about microservices. So what is the point? The author spends a lot of time talking about how to talk to stake holders to understand the requirements. OK. I'm totally behind the developers having complete understanding of what they are working on and what the expected results roughly should be like. But as far as I can tell, this has nothing to do with domain driven design _per se_. You can have complete understanding of the project, and implement the project successfully, without ever bothering with DDD.

m110 5y ago
DDD is just one way to do it. You can as well call it „Focus on what you’re solving instead of implementation details”. DDD just provides patterns to follow this approach. It’s easy to say „just write simple code”, but how do you do it? It’s not an advice someone can follow. Complex domains have many challenges where having patterns helps.
geodel 5y ago
You are right. In their mind author does think of themselves as renaissance man while preferring one set of cliches to another. I guess for some it is simply hard to grasp that one can have good understanding of software development without cramming endless design patterns and methodology acronyms.
- m110 5y ago
  Can you share how to reach this understanding? How would you learn it if not from a set of patterns and guidelines? It’s like saying „write good software” without any advice how to do it.
  - ratww 5y ago
    Software Engineering more of a craft. The only way to learn is by continuously practicing, collaborating with others and studying other people's code deeply. Design Patterns are not a catalog of recipes that you can use to put together a functioning system. They are instead an attempt at creating a "common language" of sorts for some common concepts. They don't really teach you anything about good software: they only allow experienced people to communicate well. The authors themselves have stated: "design patterns are descriptive, not prescriptive". What one has to learn, instead, is the foundational knowledge that was used for building those "patterns and guidelines", and even for other things like SOLID. And dare I say and even functional programming, OOP and procedural programming itself. For example: • Why you don't want tight coupling (foundation of lots of patterns and architectures) • How to make program state predictable and why it's important (foundation of both OOP and FP, including encapsulation and immutability. And also of some patterns like CQRS) • How to design good interfaces/APIs on all levels (functions, classes, modules, libraries, services, programs, companies) • How to understand the cost of hidden dependencies (not talking about libraries, more like "functions that call other functions" or "classes that depend on other classes". This is Joe Armstrong's banana-gorilla-jungle problem) • How to make functions/classes/modules that you can change without requiring cascading code changes in the rest of the program (again this has to do with coupling) • How to make programs predictable in general (the most important business wise)
    - m110 5y ago
      So you’re saying because software is a „craft” you can’t write down ideas how to do it better? Your bullet points are exactly this. The only thing that makes them different from „patterns” is you didn’t give them a name.

by hsn915 5y ago

m110 5y ago

DDD is just one way to do it. You can as well call it „Focus on what you’re solving instead of implementation details”. DDD just provides patterns to follow this approach. It’s easy to say „just write simple code”, but how do you do it? It’s not an advice someone can follow. Complex domains have many challenges where having patterns helps.

geodel 5y ago

You are right. In their mind author does think of themselves as renaissance man while preferring one set of cliches to another. I guess for some it is simply hard to grasp that one can have good understanding of software development without cramming endless design patterns and methodology acronyms.

m110 5y ago
Can you share how to reach this understanding? How would you learn it if not from a set of patterns and guidelines? It’s like saying „write good software” without any advice how to do it.
- ratww 5y ago
  Software Engineering more of a craft. The only way to learn is by continuously practicing, collaborating with others and studying other people's code deeply. Design Patterns are not a catalog of recipes that you can use to put together a functioning system. They are instead an attempt at creating a "common language" of sorts for some common concepts. They don't really teach you anything about good software: they only allow experienced people to communicate well. The authors themselves have stated: "design patterns are descriptive, not prescriptive". What one has to learn, instead, is the foundational knowledge that was used for building those "patterns and guidelines", and even for other things like SOLID. And dare I say and even functional programming, OOP and procedural programming itself. For example: • Why you don't want tight coupling (foundation of lots of patterns and architectures) • How to make program state predictable and why it's important (foundation of both OOP and FP, including encapsulation and immutability. And also of some patterns like CQRS) • How to design good interfaces/APIs on all levels (functions, classes, modules, libraries, services, programs, companies) • How to understand the cost of hidden dependencies (not talking about libraries, more like "functions that call other functions" or "classes that depend on other classes". This is Joe Armstrong's banana-gorilla-jungle problem) • How to make functions/classes/modules that you can change without requiring cascading code changes in the rest of the program (again this has to do with coupling) • How to make programs predictable in general (the most important business wise)
  - m110 5y ago
    So you’re saying because software is a „craft” you can’t write down ideas how to do it better? Your bullet points are exactly this. The only thing that makes them different from „patterns” is you didn’t give them a name.