Domain Driven Design - a new hype
-
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.
-
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
Marc Clifton wrote:
What book/site are you reading? That at least has more meat to it than I've encountered.
I am reading Domain Driven Design by Evans: http://books.google.no/books?id=7dlaMs0SECsC&dq=domain+driven+design&pg=PP1&ots=ulyP23_6u6&sig=Qt5nA1JUGaJhKLITdsLbti9fy0U&hl=no&prev=http://www.google.no/search?client=firefox-a&rls=org.mozilla:en-US:official&channel=s&hl=no&q=domain+driven+design&btnG=Google-s%C3%B8k&sa=X&oi=print&ct=title&cad=one-book-with-thumbnail[^]
Marc Clifton wrote:
I don't see how you can have a value without identifying who/what that value is.
Perhaps this was not the best example of them all. DDD defines very clearly what an Entity is, and what a Value is. But sometimes the identification is blurry: Something can be a value in one context, but an entity in another. I guess my database example applies to an aggregate, an entity, consisting of value object. And when I think of it, currency is probably not a value object.
Marc Clifton wrote:
The point of language is not to reduce complexity, but to increase accuracy
I don't see any conflicts here. When we apply an accurate language to our code, we remove the need to constantly map our constructs to whatever our customer calls it. That alone will contribute to lower complexity. Perhaps it's more precise to say that we apply DDD to reduce complexity, and the accurate language is one of our tools to do that.
-
I'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.Webster lists both forms. I agree with you, I like
genii. The original question from peterchen, though, was, "What's the collective noun for geniuses? A shine of geniuses?" As I don't know the answer to that, I'll have to make one up if I can't find one.BDF A learned fool is more a fool than an ignorant fool. -- Moliere
-
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
Hi, As with any new kid on the block, there are many pro's and cons as summed up in earlier replies. But if you're from the data/domain modeling hoods, DDD is a rather logical follow-up. It has many merits, indeed specifically on *new* tracks/projects. I wrote an article on DDD that appeared in December in the Dutch .Net magazine, unfortunately that's not quite legible due to the Dutch. I hope to do a rewrite of it into a CP article soon. Here's a bloglink with some additional books/readings. http://weblogs.asp.net/pgielens/archive/2007/09/19/guide-to-start-with-domain-driven-design.aspx[^] regards, Arjan Keene
-
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
Hi, Ah, a very interesting message and discussion in my opinion! Thanks! Since I was at that workshop, I'd like to comment. ;-) - Just because it took *me* several years to learn "enough" DDD doesn't mean that it will take you as long time to learn "enough" today. I would guess it will go much faster now. (And I actually find it hard to carefully say how long it took. What should I consider? When I first tried to understand OO? When I tried out different OO-ish designs? Only the time after the DDD book was published? And so on...) That said, coming from a data-driven approach most people will have to expect a learning curve. I also think it's very much about continous learning. We do learn all the time. And we should... - A very efficient way of learning is of course to work with someone that has the skill you would like to learn. Combinations are extremely powerful in my opinion when it comes to learning so just going for books is "too little" I think. I strongly believe that if you find the right person, he/she can probably teach you lots in days/weeks that took that person months/years to learn. - Porting your old system would probably take a lot of time, but as others here have commented it's hard to know if it's a good idea at all in this case. Perhaps/perhaps not, we can only guess. :-) But what I also think I answered that question with was that I dislike automatic approaches most often. It's probably not a good idea to just take the db-schema and generate all the classes to get a DDD-solution. Sure, it would go fast, but I would guess you haven't won that much. Most often you would prefer to rethink the whole thing, probably from a customer perspective. Or perhaps you only need to port a small portion of it... Or... Again, all we can do is guessing. :-) Good luck with your project! Cheers, Jimmy http://JimmyNilsson.com/blog/ ###
-
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
Really value identity means something that you wouldn't need a database ID for, so you can embed the value as fields in a table if you want. But you are supposed to pretend that you aren't talking about implementation.