Domain Driven Design - a new hype
-
K.v.S. wrote:
It's silly to put every thing in objects
I agree. ;)
But who is the king of all of these folks?
-
Yesterday I have attended a sort of workshop on Domain Driven Design, which seems to me that is radically different from Database Centric Systems. I can see some(???) benefit in it but on asking the following questions, I was not impressed anymore: Q: We have a very large database centric system, how long do you think it will take to move to a DDD system and how will you go about it for new systems? A: At first it will be an enormous task and it can take years. First you need to encapsulate your existing systems and then write data adapters for the DDD systems to talk to the old systems and eventually move the old databases to the new environment. My Comment: I can live with it even if it means double work at one stage. But the following question stumped me. Q: Since you (Jimmy Nilsson , author of "Applying Domain-Driven Design and Patterns: With Examples in C# and .Net" ) have moved from database centric systems to DDD systems, how did you start and how long did it took you to become proficient enough to be comfortable in DDD? (the answer is a shortened version) A: By reading books on the topic and it took years. My Comment: Wow!!! Over the years I taught myself using examples and sample code and a zillion books on software design and code. For DDD I can get hold of a few books, but practical examples and sample code is not freely available - about non-existent, and I do not have years right now to learn DDD, nor moving existing database centric systems to DDD systems.:confused:
the confused are confused beyond confusion
Hmm.. and the benefits of DDD are...? Seems to me they would have to be awesome to justify the time/cost/disruption to most businesses to redesign an application. Reading your post it seems that DDD: a) takes longer than database-centric design b) requires a lot of extra skills/training Maybe a new application might justify it but not porting an existing one.. Howard
'Howard
-
I share the same feelings. I am busy with Martin Fowler's book "Patterns of Enterprise Application Architecture" and find it quite interesting, but as said, it is a total mind shift change, and believe it or not, our company are only now about to move away from VB6 to .NET and the idea is to move to DDD as well. I am about the only one who has done some C# development and the rest of the team has still to catch up with .NET as well. So I see some dark nights looming.... Maybe I should take my 4x4 and travel into Africa... less bits and bytes there except for mosquitoes and a few stray bullets...
the confused are confused beyond confusion
pierrecor wrote:
believe it or not, our company are only now about to move away from VB6 to .NET
It's not such a surprise. We've got a few litle apps turning up in .net here and there but the bulk of the department's work is still done in VB6. I never thought i'd get to learn so much bout interop but hey it's been fun. Russ
-
DDD should help you stop thinking in tables & records and finally think objects. :(( It's silly to put every thing in objects: GUI, support code etc. but not your business logic, the one reason your building the system in the first place. Leave the off-line storage (DB) to the O/R mapper :-D
Hi all, :) It's silly to put every thing in objects: GUI Much of the work around Object oriented come from handling the GUI, so I don't think it is _so_ silly. ;) Having a good OO-design driven by the model can give you more flexibility in how you compose your UI and how the business rules are applied as a reply to the UI event. This point is important when you are delivering a product build around a "standard" software. Leave the off-line storage (DB) to the O/R mapper +1 on this... :)
-- greetings, Dom
-
I've read his book, and have some mixed feelings about it all. I admit there's a kind of beauty in the simplicity of DDD, both in the process and the resulting system. Also, some of the tools used, especially TDD, are universal in their benefits and can be used regardless of the development process one uses. On the other hand, it does seem to take quite some time to perfect (as you post also shows), and a bad DDD can be fatal for the system. And my biggest problem with DDD is that although our usual data-centric design might not be in vogue or beautiful, then if done right (and it's easier to do right than DDD) it is more than adequate. And sometimes "good enough" is simply that.
"When you have made evil the means of survival, do not expect men to remain good. Do not expect them to stay moral and lose their lives for the purpose of becoming the fodder of the immoral. Do not expect them to produce, when production is punished and looting rewarded. Do not ask, `Who is destroying the world?' You are."
-Atlas Shrugged, Ayn RandCOuld you define the core of DDD or "DD vs. Server Centric" in a few words?
Rohde wrote:
it does seem to take quite some time to perfect (as you post also shows), and a bad DDD can be fatal for the system.
One famous security guy once wrote an interesting piece about judging security systems - the gist of it being: Judge systems by how they fail. Instead of looking at minor security gains achieved when the system works, compare systems by looking at what happens when they fail - e.g. you have a false positive. I think that applis not only to security systems, but can be applied to many other things - such as Project Management and Software design paradigms: How bad things get when your team fails to excel? Can an average team sucessfully implement this paradigm, or do you need a bunch of geniuses for this? (what's the collective noun for geniuses? A shine of geniuses?)
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist -
Yesterday I have attended a sort of workshop on Domain Driven Design, which seems to me that is radically different from Database Centric Systems. I can see some(???) benefit in it but on asking the following questions, I was not impressed anymore: Q: We have a very large database centric system, how long do you think it will take to move to a DDD system and how will you go about it for new systems? A: At first it will be an enormous task and it can take years. First you need to encapsulate your existing systems and then write data adapters for the DDD systems to talk to the old systems and eventually move the old databases to the new environment. My Comment: I can live with it even if it means double work at one stage. But the following question stumped me. Q: Since you (Jimmy Nilsson , author of "Applying Domain-Driven Design and Patterns: With Examples in C# and .Net" ) have moved from database centric systems to DDD systems, how did you start and how long did it took you to become proficient enough to be comfortable in DDD? (the answer is a shortened version) A: By reading books on the topic and it took years. My Comment: Wow!!! Over the years I taught myself using examples and sample code and a zillion books on software design and code. For DDD I can get hold of a few books, but practical examples and sample code is not freely available - about non-existent, and I do not have years right now to learn DDD, nor moving existing database centric systems to DDD systems.:confused:
the confused are confused beyond confusion
Idiots. First, DDD is a rehash of existing concepts. Second, it's really good at stating the problem (complexity is a problem) without providing a solution, except for "buy my book". Third, and most importantly, it seems this concept is stated on various sites: Domain Driven Design is a vision and approach for dealing with highly complex domains that is based on making the domain itself the main focus of the project Idiots. You don't deal with complexity by making the domain the main focus of the project, you deal with complexity by abstracting away the domain, then you go back and model the domain through schema, workflow, state, decision graphs, and other obvious meta-techniques!!! So, you heard it first here: ADD - Abstraction Driven Design!!! Can you ADD???? (feel free to point out the other obvious meanings) ;P Marc
-
Yesterday I have attended a sort of workshop on Domain Driven Design, which seems to me that is radically different from Database Centric Systems. I can see some(???) benefit in it but on asking the following questions, I was not impressed anymore: Q: We have a very large database centric system, how long do you think it will take to move to a DDD system and how will you go about it for new systems? A: At first it will be an enormous task and it can take years. First you need to encapsulate your existing systems and then write data adapters for the DDD systems to talk to the old systems and eventually move the old databases to the new environment. My Comment: I can live with it even if it means double work at one stage. But the following question stumped me. Q: Since you (Jimmy Nilsson , author of "Applying Domain-Driven Design and Patterns: With Examples in C# and .Net" ) have moved from database centric systems to DDD systems, how did you start and how long did it took you to become proficient enough to be comfortable in DDD? (the answer is a shortened version) A: By reading books on the topic and it took years. My Comment: Wow!!! Over the years I taught myself using examples and sample code and a zillion books on software design and code. For DDD I can get hold of a few books, but practical examples and sample code is not freely available - about non-existent, and I do not have years right now to learn DDD, nor moving existing database centric systems to DDD systems.:confused:
the confused are confused beyond confusion
I think the whole point of DDD is to simplify designs that would be otherwise too complicated if implemented in any other fashion. Otherwise, it can make things worse. The ultimate litmus test for any idiom or methodology is to ask yourself whether or not the "straightforward" approach can get the job done faster and more efficiently than adding another layer of indirection to your system by using the "trendy" method. If the straightforward approach gets the job done, I say just do it using the simplest way and save yourself the trouble. If DDD doesn't make the job any easier for your current projects, then I'd take Mr. Nilsson's approach with a grain of salt, and let him do his writing while I go meet my deadlines. In short, there's no better methodology than Common Sensetm :) Anyone telling you otherwise is just trying to sell you something...like their own book. :P Caveat Emptor.
-
COuld you define the core of DDD or "DD vs. Server Centric" in a few words?
Rohde wrote:
it does seem to take quite some time to perfect (as you post also shows), and a bad DDD can be fatal for the system.
One famous security guy once wrote an interesting piece about judging security systems - the gist of it being: Judge systems by how they fail. Instead of looking at minor security gains achieved when the system works, compare systems by looking at what happens when they fail - e.g. you have a false positive. I think that applis not only to security systems, but can be applied to many other things - such as Project Management and Software design paradigms: How bad things get when your team fails to excel? Can an average team sucessfully implement this paradigm, or do you need a bunch of geniuses for this? (what's the collective noun for geniuses? A shine of geniuses?)
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighistThe problem, they state, is that the data-centric paradigm suffers for some problems. For instance such a model is usually tied to some technicalities that might change. Also, you system has a tendency to end up as a procedural model shoehorned into the OOP paradigm, resulting in a system that's inflexible and not as maintainable as it should be. Also the system does not usually describe the requirements directly. DDD is about focusing on the model and have less infrastructure and technical focus. So instead of focus on building in support for technicalities that may come and go, e.g. UI, focus on the core business model. It's also about not letting use cases (which is good in DDD) forcing you into a procedural thinking. In DDD, the domain model should be the language for the system requirements - that's what they call the "ubiquitous language". All this is accomplished using entity objects, value objects, repositories, and factories (design patterns which I'm sure you know of). Now, the hard part about it is that one's reaction might be "but aren't we doing this already?". The truth is no; not in the DDD way. And it is a big mind shift to shift focus form your data to your domain model. [Obviously this is only my understanding of it and I've only read Nilsson's book and not Evans' which started it all so I'm not an expert on DDD.]
"When you have made evil the means of survival, do not expect men to remain good. Do not expect them to stay moral and lose their lives for the purpose of becoming the fodder of the immoral. Do not expect them to produce, when production is punished and looting rewarded. Do not ask, `Who is destroying the world?' You are."
-Atlas Shrugged, Ayn Rand -
Idiots. First, DDD is a rehash of existing concepts. Second, it's really good at stating the problem (complexity is a problem) without providing a solution, except for "buy my book". Third, and most importantly, it seems this concept is stated on various sites: Domain Driven Design is a vision and approach for dealing with highly complex domains that is based on making the domain itself the main focus of the project Idiots. You don't deal with complexity by making the domain the main focus of the project, you deal with complexity by abstracting away the domain, then you go back and model the domain through schema, workflow, state, decision graphs, and other obvious meta-techniques!!! So, you heard it first here: ADD - Abstraction Driven Design!!! Can you ADD???? (feel free to point out the other obvious meanings) ;P Marc
I still thinking about the 4x4 thing... travelling Africa. Maybe when I'm back (if) ADD will be in full swing... with a few books and articles on it. How much more do we need to know... and apply. But what the heck, we love it and we do it. My biggest concern - if the DDD expert leaves the company (on a 4x4 trip perhaps) who is going to maintain the systems. Now according to DDD, once done correct, you do NOT have to maintain systems, or do I miss a point here? All the years you have designed in a lateral way, UI --> Bussines --> Data. Now all of a sudden it is in the vertical... :confused: Eish! (Eish is an South African word meaning more or less... "now what the heck does he mean with that statement..." or "that was a stupid question/statement...") :)
the confused are confused beyond confusion
-
Idiots. First, DDD is a rehash of existing concepts. Second, it's really good at stating the problem (complexity is a problem) without providing a solution, except for "buy my book". Third, and most importantly, it seems this concept is stated on various sites: Domain Driven Design is a vision and approach for dealing with highly complex domains that is based on making the domain itself the main focus of the project Idiots. You don't deal with complexity by making the domain the main focus of the project, you deal with complexity by abstracting away the domain, then you go back and model the domain through schema, workflow, state, decision graphs, and other obvious meta-techniques!!! So, you heard it first here: ADD - Abstraction Driven Design!!! Can you ADD???? (feel free to point out the other obvious meanings) ;P Marc
In some ways, this is worse than a dog chasing it's own tail--it's like a dog growing a whole new tail so that it can begin to chase itself all over again! DDD - Distraction using Domain Design.
-
COuld you define the core of DDD or "DD vs. Server Centric" in a few words?
Rohde wrote:
it does seem to take quite some time to perfect (as you post also shows), and a bad DDD can be fatal for the system.
One famous security guy once wrote an interesting piece about judging security systems - the gist of it being: Judge systems by how they fail. Instead of looking at minor security gains achieved when the system works, compare systems by looking at what happens when they fail - e.g. you have a false positive. I think that applis not only to security systems, but can be applied to many other things - such as Project Management and Software design paradigms: How bad things get when your team fails to excel? Can an average team sucessfully implement this paradigm, or do you need a bunch of geniuses for this? (what's the collective noun for geniuses? A shine of geniuses?)
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighistI'll answer the most important question...
cactus->cacti, so,genius->genii.! Sounds like they grant wishes to, so bonus there! According to www.dictionary.com it'sgeniuses, but I'm sure I'm right, and they're wrong. I'm not in *any* way arrogant. I've got too much modesty for that... Iain. -
Yesterday I have attended a sort of workshop on Domain Driven Design, which seems to me that is radically different from Database Centric Systems. I can see some(???) benefit in it but on asking the following questions, I was not impressed anymore: Q: We have a very large database centric system, how long do you think it will take to move to a DDD system and how will you go about it for new systems? A: At first it will be an enormous task and it can take years. First you need to encapsulate your existing systems and then write data adapters for the DDD systems to talk to the old systems and eventually move the old databases to the new environment. My Comment: I can live with it even if it means double work at one stage. But the following question stumped me. Q: Since you (Jimmy Nilsson , author of "Applying Domain-Driven Design and Patterns: With Examples in C# and .Net" ) have moved from database centric systems to DDD systems, how did you start and how long did it took you to become proficient enough to be comfortable in DDD? (the answer is a shortened version) A: By reading books on the topic and it took years. My Comment: Wow!!! Over the years I taught myself using examples and sample code and a zillion books on software design and code. For DDD I can get hold of a few books, but practical examples and sample code is not freely available - about non-existent, and I do not have years right now to learn DDD, nor moving existing database centric systems to DDD systems.:confused:
the confused are confused beyond confusion
The goal of DDD, or one of them, is to create a common language for all parties. That means developers, business analytics and customers all use the same words and phrasing. It will take time to fully understand the domain, so this is something we have to apply piecemeal. Like eating the elephant. This language is then used to reduce complexity. We name our objects and services by the same names, and they will have the same interactions. Then there are some rules to adhere to. I have only scratched the surface, but I found the use of Repositories, Entities, Value Objects and Aggregates to be especially powerful. Just by applying those, I found a deeper understanding of the customers domain and saw numerous ways to improve my code. That goes for database design as well. One example: If your aggregate contains a collection of value objects, and you need to update some of them in the database: Just delete them and insert them anew. That is because a value object is not identified by who they are (that's an entity), but by the value(s) they have. Color is one example. Currency another.
-
Idiots. First, DDD is a rehash of existing concepts. Second, it's really good at stating the problem (complexity is a problem) without providing a solution, except for "buy my book". Third, and most importantly, it seems this concept is stated on various sites: Domain Driven Design is a vision and approach for dealing with highly complex domains that is based on making the domain itself the main focus of the project Idiots. You don't deal with complexity by making the domain the main focus of the project, you deal with complexity by abstracting away the domain, then you go back and model the domain through schema, workflow, state, decision graphs, and other obvious meta-techniques!!! So, you heard it first here: ADD - Abstraction Driven Design!!! Can you ADD???? (feel free to point out the other obvious meanings) ;P Marc
Good points you made there, but did you have to insult all of in the process? We are, after all, trying to learn and understand this thing.
-
Good points you made there, but did you have to insult all of in the process? We are, after all, trying to learn and understand this thing.
Thomas Eyde wrote:
but did you have to insult all of in the process
Ah, you have to ignore my first post of the morning. :) Marc
-
I still thinking about the 4x4 thing... travelling Africa. Maybe when I'm back (if) ADD will be in full swing... with a few books and articles on it. How much more do we need to know... and apply. But what the heck, we love it and we do it. My biggest concern - if the DDD expert leaves the company (on a 4x4 trip perhaps) who is going to maintain the systems. Now according to DDD, once done correct, you do NOT have to maintain systems, or do I miss a point here? All the years you have designed in a lateral way, UI --> Bussines --> Data. Now all of a sudden it is in the vertical... :confused: Eish! (Eish is an South African word meaning more or less... "now what the heck does he mean with that statement..." or "that was a stupid question/statement...") :)
the confused are confused beyond confusion
pierrecor wrote:
Now according to DDD, once done correct, you do NOT have to maintain systems, or do I miss a point here?
That's the main part where it falls apart. Domains change. Highway tolls are replaced with ez-pass. Phones are replaced with VOIP. Oil distribution systems are replaced with hydrogen or electric systems. The point of abstracting the domain is so that you create an architecture that is flexible and maintainable for the inevitable change that will occur to the domain. Not to mention that the domain often changes during development. That's another fallacy of DDD, it looks like. If it takes years to replace an existing application, do you think the world, the domain, will hold still while that development takes place? No! Marc
-
The goal of DDD, or one of them, is to create a common language for all parties. That means developers, business analytics and customers all use the same words and phrasing. It will take time to fully understand the domain, so this is something we have to apply piecemeal. Like eating the elephant. This language is then used to reduce complexity. We name our objects and services by the same names, and they will have the same interactions. Then there are some rules to adhere to. I have only scratched the surface, but I found the use of Repositories, Entities, Value Objects and Aggregates to be especially powerful. Just by applying those, I found a deeper understanding of the customers domain and saw numerous ways to improve my code. That goes for database design as well. One example: If your aggregate contains a collection of value objects, and you need to update some of them in the database: Just delete them and insert them anew. That is because a value object is not identified by who they are (that's an entity), but by the value(s) they have. Color is one example. Currency another.
Thomas Eyde wrote:
I have only scratched the surface, but I found the use of Repositories, Entities, Value Objects and Aggregates to be especially powerful.
What book/site are you reading? That at least has more meat to it than I've encountered.
Thomas Eyde wrote:
One example: If your aggregate contains a collection of value objects, and you need to update some of them in the database: Just delete them and insert them anew. That is because a value object is not identified by who they are (that's an entity), but by the value(s) they have. Color is one example. Currency another.
I find it unsettling to take that approach. Value seems meaningless unless it is associated with a concept. It seems to me that the concept identifies the value, so you now have an entity. By the very fact of saying "currency" you have identified the value. And therefore, simply deleting and inserting new currency values is not always the right approach. I don't see how you can have a value without identifying who/what that value is. <blockquote class="FQ"><div class="FQA">Thomas Eyde wrote:</div>This language is then used to reduce complexity. We name our objects and services by the same names, and they will have the same interactions. </blockquote> Hmmm. The point of language is not to reduce complexity, but to increase accuracy. Accuracy reveals complexity rather than hiding it. If we all use the same names for different concepts, we lose accuracy (information and meaning). It then becomes confusing as to what we are talking about. The word "domain" is itself so overloaded it doesn't convey any meaning anymore because we don't know which of the overloaded meanings is intended. So, in my thinking, naming things the same name is a bad thing. Marc
-
pierrecor wrote:
Now according to DDD, once done correct, you do NOT have to maintain systems, or do I miss a point here?
That's the main part where it falls apart. Domains change. Highway tolls are replaced with ez-pass. Phones are replaced with VOIP. Oil distribution systems are replaced with hydrogen or electric systems. The point of abstracting the domain is so that you create an architecture that is flexible and maintainable for the inevitable change that will occur to the domain. Not to mention that the domain often changes during development. That's another fallacy of DDD, it looks like. If it takes years to replace an existing application, do you think the world, the domain, will hold still while that development takes place? No! Marc
Marc Clifton wrote:
That's another fallacy of DDD, it looks like. If it takes years to replace an existing application, do you think the world, the domain, will hold still while that development takes place? No!
That was well said. All in all, I think if you have a complex company spanning different countries, perhaps it is worthwhile to invest in DDD, otherwise, if you have fairly large but not so complex systems, why not keep on designing the Database Centric way? You'll always get someone who'll be able with a bit of effort (and no documentation) to maintain the systems. I cannot say the same for DDD. With all respect, married women go on maternity leave, people (even those in IT) go on leave or get sick, or some lose control over their bikes and cars. What then? As a conclusion, personally I'll put in all the effort to "study" and apply DDD; the question is, is the rest of the team ready - is the company ready? One will need a sponsor who'll have to understand the phrase "it's going to take a looooong time to deliver... and we are not even talking about maintenance for now!" Supposedly DDD is self explanatory... you need no documentation. And of the total IT community, how many can do DDD?
not so confused anymore....
-
Thomas Eyde wrote:
but did you have to insult all of in the process
Ah, you have to ignore my first post of the morning. :) Marc
Marc Clifton wrote:
Ah, you have to ignore my first post of the morning.
Indeed. The inevitable daily "off by one" error. :)
:josh: My WPF Blog[^] All of life is just a big rambling blog post.
-
Hmm.. and the benefits of DDD are...? Seems to me they would have to be awesome to justify the time/cost/disruption to most businesses to redesign an application. Reading your post it seems that DDD: a) takes longer than database-centric design b) requires a lot of extra skills/training Maybe a new application might justify it but not porting an existing one.. Howard
'Howard
Howard Richards wrote:
Maybe a new application might justify it but not porting an existing one..
That was my reaction, too. Unless you're already dead-set on rewriting the old beast, I'd say let sleeping dogs lie.
:josh: My WPF Blog[^] All of life is just a big rambling blog post.