Domain Driven Design and Spherical cows
-
I was just reading an excerpt from : Patterns, Principles, and Practices of Domain-Driven Design: Scott Millett, Nick Tune: 0787721845461: Amazon.com: Books[^]
Book Quote:
Selling DDD DDD is not a silver bullet, and it shouldn’t be sold as one. In the same way that following an agile methodology won’t solve all of your problems, neither will DDD; however, it is a powerful and extremely effective philosophy when used in the correct circumstances, such as these: + You have a skilled, motivated, and passionate team that is eager to learn. + You have a nontrivial problem domain that is important to your business. + You have access to domain experts who are aligned to the vision of the project. + You are following an iterative development methodology. Without these key ingredients, applying the principles and practices of DDD will overcomplicate your development effort rather than simplify it. However, if your particular circumstances meet the preceding list, then applying the principles and practices of DDD can greatly increase the value of your development effort.
Uh, have you ever had the alignment of all four of those circumstances on any project ever? :rolleyes: Requirement #3 from the list is especially under scrutiny here. :cool: Maybe DDD is only for hypothetical situations like Spherical cows (Wikipedia).[^]
I suspect that point three means, "you must hire a consultant who understands DDD... and I'm the only one."
-
I was just reading an excerpt from : Patterns, Principles, and Practices of Domain-Driven Design: Scott Millett, Nick Tune: 0787721845461: Amazon.com: Books[^]
Book Quote:
Selling DDD DDD is not a silver bullet, and it shouldn’t be sold as one. In the same way that following an agile methodology won’t solve all of your problems, neither will DDD; however, it is a powerful and extremely effective philosophy when used in the correct circumstances, such as these: + You have a skilled, motivated, and passionate team that is eager to learn. + You have a nontrivial problem domain that is important to your business. + You have access to domain experts who are aligned to the vision of the project. + You are following an iterative development methodology. Without these key ingredients, applying the principles and practices of DDD will overcomplicate your development effort rather than simplify it. However, if your particular circumstances meet the preceding list, then applying the principles and practices of DDD can greatly increase the value of your development effort.
Uh, have you ever had the alignment of all four of those circumstances on any project ever? :rolleyes: Requirement #3 from the list is especially under scrutiny here. :cool: Maybe DDD is only for hypothetical situations like Spherical cows (Wikipedia).[^]
raddevus wrote:
+ You have a skilled, motivated, and passionate team that is eager to learn. + You have a nontrivial problem domain that is important to your business. + You have access to domain experts who are aligned to the vision of the project. + You are following an iterative development methodology.
Sure. Only recently, I contracted to a place that worked on weather systems for airports -- i.e. we were working on getting planes off the ground and on the ground safely, with the knowledge that if we screwed it up, people could die. I can say, in all honesty, that I have never worked with a more dedicated team of skilled, knowledgeable people, who did an absolutely fantastic, professional job using the agile methodology, which, to be honest, didn't count for a damn, in our minds -- any other methodology would have worked as well. Maybe it makes a difference if what you do will make more money for some unidentified bunch of shareholders, rather than make sure that children see their parents again, but the shareholders made more money, too. So it was why we were doing what we were doing doing that counted, not any silly flavour-of-the-month way of doing it. If you don't believe in what you're doing, look for another job, not another way of working.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Marc Clifton wrote:
It's the 5th element that was missing. Manager vision. The VP who had the vision retired
Oh, no Product Owner[^]? Very bad indeed. Can't even get to the other four items without that driving force really. That's a good one to add to the list of items required. And pushes the Spherical Cow further out of our reach. :laugh:
A good team only needs a manager to help clear the way for the team to do a good job. A good manager only clears the way for his team(s) to do a good job. Find out what's not working, and see if there's a way to fix it if it's not.
I wanna be a eunuchs developer! Pass me a bread knife!
-
I was just reading an excerpt from : Patterns, Principles, and Practices of Domain-Driven Design: Scott Millett, Nick Tune: 0787721845461: Amazon.com: Books[^]
Book Quote:
Selling DDD DDD is not a silver bullet, and it shouldn’t be sold as one. In the same way that following an agile methodology won’t solve all of your problems, neither will DDD; however, it is a powerful and extremely effective philosophy when used in the correct circumstances, such as these: + You have a skilled, motivated, and passionate team that is eager to learn. + You have a nontrivial problem domain that is important to your business. + You have access to domain experts who are aligned to the vision of the project. + You are following an iterative development methodology. Without these key ingredients, applying the principles and practices of DDD will overcomplicate your development effort rather than simplify it. However, if your particular circumstances meet the preceding list, then applying the principles and practices of DDD can greatly increase the value of your development effort.
Uh, have you ever had the alignment of all four of those circumstances on any project ever? :rolleyes: Requirement #3 from the list is especially under scrutiny here. :cool: Maybe DDD is only for hypothetical situations like Spherical cows (Wikipedia).[^]
-
I was just reading an excerpt from : Patterns, Principles, and Practices of Domain-Driven Design: Scott Millett, Nick Tune: 0787721845461: Amazon.com: Books[^]
Book Quote:
Selling DDD DDD is not a silver bullet, and it shouldn’t be sold as one. In the same way that following an agile methodology won’t solve all of your problems, neither will DDD; however, it is a powerful and extremely effective philosophy when used in the correct circumstances, such as these: + You have a skilled, motivated, and passionate team that is eager to learn. + You have a nontrivial problem domain that is important to your business. + You have access to domain experts who are aligned to the vision of the project. + You are following an iterative development methodology. Without these key ingredients, applying the principles and practices of DDD will overcomplicate your development effort rather than simplify it. However, if your particular circumstances meet the preceding list, then applying the principles and practices of DDD can greatly increase the value of your development effort.
Uh, have you ever had the alignment of all four of those circumstances on any project ever? :rolleyes: Requirement #3 from the list is especially under scrutiny here. :cool: Maybe DDD is only for hypothetical situations like Spherical cows (Wikipedia).[^]
All of this crap that has been promoted in the last 15 to 20 years is all based on utopian visions of the software engineering world that simply does not exist in reality. You use the simplest technologies to get the job done as fast and as efficiently as possible to meet ridiculous deadlines setup by incompetent technical managers. The rest is just vendor marketing and self-aggrandizement by those who want you to believe they have the answers for everything...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
I was just reading an excerpt from : Patterns, Principles, and Practices of Domain-Driven Design: Scott Millett, Nick Tune: 0787721845461: Amazon.com: Books[^]
Book Quote:
Selling DDD DDD is not a silver bullet, and it shouldn’t be sold as one. In the same way that following an agile methodology won’t solve all of your problems, neither will DDD; however, it is a powerful and extremely effective philosophy when used in the correct circumstances, such as these: + You have a skilled, motivated, and passionate team that is eager to learn. + You have a nontrivial problem domain that is important to your business. + You have access to domain experts who are aligned to the vision of the project. + You are following an iterative development methodology. Without these key ingredients, applying the principles and practices of DDD will overcomplicate your development effort rather than simplify it. However, if your particular circumstances meet the preceding list, then applying the principles and practices of DDD can greatly increase the value of your development effort.
Uh, have you ever had the alignment of all four of those circumstances on any project ever? :rolleyes: Requirement #3 from the list is especially under scrutiny here. :cool: Maybe DDD is only for hypothetical situations like Spherical cows (Wikipedia).[^]
Quote:
have you ever had the alignment of all four of those circumstances on any project ever?
Yes. I was the only member of the team. And I was a domain expert. :)
Cheers, Mike Fidler "I intend to live forever - so far, so good." Steven Wright "I almost had a psychic girlfriend but she left me before we met." Also Steven Wright "I'm addicted to placebos. I could quit, but it wouldn't matter." Steven Wright yet again.
-
I was just reading an excerpt from : Patterns, Principles, and Practices of Domain-Driven Design: Scott Millett, Nick Tune: 0787721845461: Amazon.com: Books[^]
Book Quote:
Selling DDD DDD is not a silver bullet, and it shouldn’t be sold as one. In the same way that following an agile methodology won’t solve all of your problems, neither will DDD; however, it is a powerful and extremely effective philosophy when used in the correct circumstances, such as these: + You have a skilled, motivated, and passionate team that is eager to learn. + You have a nontrivial problem domain that is important to your business. + You have access to domain experts who are aligned to the vision of the project. + You are following an iterative development methodology. Without these key ingredients, applying the principles and practices of DDD will overcomplicate your development effort rather than simplify it. However, if your particular circumstances meet the preceding list, then applying the principles and practices of DDD can greatly increase the value of your development effort.
Uh, have you ever had the alignment of all four of those circumstances on any project ever? :rolleyes: Requirement #3 from the list is especially under scrutiny here. :cool: Maybe DDD is only for hypothetical situations like Spherical cows (Wikipedia).[^]
This is kind of triple-D I prefer; though I've never seen it put into practice, it seems like it would work in a reasonable manner - and really isn't far from what many of us do already: Meme Agora: D-Cubed[^] D^3 - Defect Driven Design It's an old idea (and unfortunately, the original source can't be found any longer), but if implemented properly, in theory it would always result in an application that is -exactly- fit to the requirements of the client. Essentially, you pretend your project is already in maintenance mode, and you're just fixing "bugs". Sooner or later, that's where you're going to end up anyhow, so why not start there at the beginning?
-
All of this crap that has been promoted in the last 15 to 20 years is all based on utopian visions of the software engineering world that simply does not exist in reality. You use the simplest technologies to get the job done as fast and as efficiently as possible to meet ridiculous deadlines setup by incompetent technical managers. The rest is just vendor marketing and self-aggrandizement by those who want you to believe they have the answers for everything...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
That's actually a very good summary of the situation. APIs and Magic Libraries that will supposedly solve everything are often the cause of more problems. And, the daft managers don't understand that the Marketing Propaganda of the APIs and Libaries are often not true (seldom true) and then the mgr gets the idea that it is the dev who is incompetent when it is really a problem with the Magic Library. :sigh:
-
This is kind of triple-D I prefer; though I've never seen it put into practice, it seems like it would work in a reasonable manner - and really isn't far from what many of us do already: Meme Agora: D-Cubed[^] D^3 - Defect Driven Design It's an old idea (and unfortunately, the original source can't be found any longer), but if implemented properly, in theory it would always result in an application that is -exactly- fit to the requirements of the client. Essentially, you pretend your project is already in maintenance mode, and you're just fixing "bugs". Sooner or later, that's where you're going to end up anyhow, so why not start there at the beginning?
-
That's actually a very good summary of the situation. APIs and Magic Libraries that will supposedly solve everything are often the cause of more problems. And, the daft managers don't understand that the Marketing Propaganda of the APIs and Libaries are often not true (seldom true) and then the mgr gets the idea that it is the dev who is incompetent when it is really a problem with the Magic Library. :sigh:
A very astute summary of what I said. Bully for you!!! :) Hopefully, the younger generations of professionals will come to realize this and will start the pendulum swinging back to a more sane time in our profession...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
I was just reading an excerpt from : Patterns, Principles, and Practices of Domain-Driven Design: Scott Millett, Nick Tune: 0787721845461: Amazon.com: Books[^]
Book Quote:
Selling DDD DDD is not a silver bullet, and it shouldn’t be sold as one. In the same way that following an agile methodology won’t solve all of your problems, neither will DDD; however, it is a powerful and extremely effective philosophy when used in the correct circumstances, such as these: + You have a skilled, motivated, and passionate team that is eager to learn. + You have a nontrivial problem domain that is important to your business. + You have access to domain experts who are aligned to the vision of the project. + You are following an iterative development methodology. Without these key ingredients, applying the principles and practices of DDD will overcomplicate your development effort rather than simplify it. However, if your particular circumstances meet the preceding list, then applying the principles and practices of DDD can greatly increase the value of your development effort.
Uh, have you ever had the alignment of all four of those circumstances on any project ever? :rolleyes: Requirement #3 from the list is especially under scrutiny here. :cool: Maybe DDD is only for hypothetical situations like Spherical cows (Wikipedia).[^]
Well, I feel that for the most part the "tactical patterns" of DDD are simply OO done right :) I do, however, feel that when developers do *not* have access to domain experts we end up with second hand information (or worse) which simply contributes to the sad state that the software development industry finds itself in.
-
Well, I feel that for the most part the "tactical patterns" of DDD are simply OO done right :) I do, however, feel that when developers do *not* have access to domain experts we end up with second hand information (or worse) which simply contributes to the sad state that the software development industry finds itself in.
EbenRoux wrote:
for the most part the "tactical patterns" of DDD are simply OO done right
I agree.
EbenRoux wrote:
when developers do *not* have access to domain experts we end up with second hand information (or worse) which simply contributes to the sad state that the software development industry finds itself in
I agree again. :) If teams really did OO right it would solve a lot of design issues that cause maintenance and extensability to be far more difficult than they have to be later. If teams really had domain experts that knew what they wanted and could explain what they wanted it would solve a lot of problems where the wrong solution is created.