Could anyone write something about the relationship to Component-based software engineering?
the diagram doesn't show a domain layer??
from the little that i know about this, the domain layer and the business layer are the same thing. in DDD this layer is referred to as the domain layer. yet in the diagram its labeled as the business layer. tres confusing. can't whoever put this page together find a better and more corresponding diagram? or do i not get it? Ronewolf (talk) 23:01, 21 October 2009 (UTC)
- Couldn't agree more - the three layers shows a traditional architecture that you would seen in lots of MSDN articles circa 2002. DDD apps typically use something more like the onion architecture with an explicit domain model at the centre. 184.108.40.206 (talk) 07:06, 22 October 2009 (UTC)
Request for feedback (Portofino framework)
I've written a new article about Portofino, an open-source web application framework written in Java and based on model-driven engineering.
The framework was mentioned in the Domain-driven design article (as "ManyDesigns Portofino"), so I would kindly ask anybody interested in the subject to review my article and provide some feedback.
I'm keeping the article under my personal page during the review process.
Non-trivial domain required for a successful DDD
Text says: Prerequisites for the successful application of DDD: Your domain is not trivial.
It is absolute valid to have a model with two domain objects. Evans has never required a domain to be complex to be applicable to this model, otherwise please cite. — Preceding unsigned comment added by 220.127.116.11 (talk) 21:41, 2 September 2011 (UTC)
While a non-complex domain is not a pre-requisite for this model, Evans does qualify that the overhead involved in the model process may not be justified for trivial models, which could be adequately treated with less formal methods. Indeed he says that simple programs for trivial models may be best served by a "smart UI" approach (by which he obviously is referring to c# / vb.net using windows forms or WPF graphical design tools). --18.104.22.168 (talk) 13:14, 16 June 2014 (UTC)Michael
|This section or list is incomplete. Please help to improve it, or discuss the issue on the talk page.|
- Hmmm. There is an extended example in Evans' book about a shipping company with cargoes and customers and handling events (Pp 163 - 186). There is another, smaller example about loans with facilities and transactions, payments etc (P. 202). There may be others, it's along time since I read the book, and I'm just skimming it now. There is also this, that I wrote myself. I am not a reliable source, and that was written in an evening three years ago. It's published under a CC licence. I cannot import it or re-write it here myself because of various policies, but I think if someone else wanted to draw on it, it would be OK, especially if better refs were found for some of the key statements. It's got a very simple example in it about a database-based messaging system. That gets more complex when you start looking at replies to replies, forwarding, attachments, message threads etc. I've worked on several other DDD projects; none of them are written up anywhere public, but I can give ideas if anyone's interested. --Nigelj (talk) 20:29, 29 March 2011 (UTC)
Maintaining Model Integrity image
doesn't read like an encyclopedia article
I'm new to Domain-Driven Design, so I don't feel that I have the background to rewrite any of this article. However, when I was reading this, it seemed like a mix of two things - an advertisement for the original book and some "Dear Abby" type advice. The first could be improved by citing more expert references (not just Wikipedia articles). The second could be improved by changing some of the language like this:
Ideally, it would be preferable to have a single, unified model. While this is a noble goal, in reality it typically fragments into multiple models. It is useful to recognize this fact of life and work with it.
...with something sounding less like "chit chat" like...
Software developers often prefer to develop a single, unified model of their problem. However, proponents of domain-driven design recognize that most unified models fragment into multiple models.
I don't even know if that's true or the intent of this section, but Wikipedia isn't here to be my coach - "that's just a fact of life, now move on". It's here to inform me.