Talk:Domain-driven design

Could anyone write something about the relationship to Component-based software engineering?

the diagram doesn't show a domain layer??

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)[reply]

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. 202.89.135.240 (talk) 07:06, 22 October 2009 (UTC)[reply]

Link farm?

I think that we might be having a link farm for the "Softwares that support DDD". A clean-up would be required. Maxime rouiller (talk) 16:41, 1 February 2010 (UTC)[reply]

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.

Predonzani (talk) 09:59, 9 February 2010 (UTC)[reply]

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 84.62.217.221 (talk) 21:41, 2 September 2011 (UTC)[reply]

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). --206.248.139.140 (talk) 13:14, 16 June 2014 (UTC)Michael[reply]

Example needed

A concrete example would be extremely useful for readers of this article. -- Beland (talk) 18:40, 29 March 2011 (UTC)[reply]

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)[reply]

There was a nice listing at this time (https://en.wikipedia.org/w/index.php?title=Domain-driven_design&oldid=1037278672) but some contributor change it to prose, so it's forever lost in the blablabla now. I think the listing made a nice example on how to proceed to start working with DDD. Probably, a concrete list shouldn't be taken as an example, rather than an abstract list, but IMO it lets you understand the concept in a quicker way. Fabiocapasso93 (talk) 14:10, 29 April 2022 (UTC)[reply]

Maintaining Model Integrity image

That is a seriously awful image. Flow charts aren't supposed to look like crazy squids. — Preceding unsigned comment added by 68.34.187.154 (talk) 00:37, 3 February 2012 (UTC)[reply]

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.

ToddBradley (talk) 14:33, 19 December 2013 (UTC)[reply]

Substantial style edit

I've tidied up the page substantially by changing the anemic bulletpoint-style headers into actual prose. I've also generally tried to make the language more encyclopedic (removing 'you's, etc) and more readable (replacing the fifty different three-letter acronyms with something halfway legible). Let me know if anything should be changed back. Telemachus12389 (talk) 16:14, 5 August 2021 (UTC)[reply]

Writergarten DDD Community

The DDD community started an activity to improve this article.

Heading text

ng Domain-Driven Design on WikiPedia The WikiPedia article on Domain-Driven Design needs to better reflect the core tennets of DDD. It should als welcome the critique on DDD and bring out various conflicting opinions in the community.

Next actions

[ ] Add sections "Strategic Design", "Tactical Design", "Ubiquitous Language"
[ ] Mention the fact that tactical patterns are optional but that binding model and implementation is mandatory
[ ] Myth: DDD is only for OO
[ ] Myth: Tactical Patterns are a finite list
[ ] Myth: Tactical Patterns were all coined by Eric
[ ] Myth: DDD prescribes a particular architecture
[ ] Source of confusion: Aggregates

   * [ ] Name of the pattern
   * [ ] Series of articles by Vaugh
       * [ ] Part 1: https://www.dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_1.pdf
       * [ ] Part 2: https://www.dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_2.pdf
       * [ ] Part 3: https://www.dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_3.pdf

[ ] Article by Paul: http://thepaulrayner.com/blog/aggregates-and-entities-in-domain-driven-design/
[ ] Add books

   * [ ] Vaughn
   * [ ] Nick Tune and Scott Millet
   * [ ] The Anatomy of DDD
   * [ ] Scott Wlaschin: Domain-Modeling-Made-Functional-Domain-Driven
   * [ ] Vladik Khonov: Learning DDD

[ ] Add community initiatives

   * [ ] dddcommunity.org
   * [ ] virtualddd.com
   * [ ] ddd-crew

[ ] Conferences

   * [ ] DDDEurope
   * [ ] KanDDDinsky
   * [ ] ExploreDDD
   * [ ] DDDExchange

https://gist.github.com/marijn/929284e9c93e7b1ca1ae8f8de15547ef — Preceding unsigned comment added by Henning Schwentner (talk • contribs)

I'm interested to see your efforts, but please have a look at Wikipedia's sourcing requirements before you proceed. In particular blogs and other social media (including posts on github) should not be used as sources. Also, have a look at WP:EL, Wikipedia generally does not link to community sites. - MrOllie (talk) 13:20, 22 October 2021 (UTC)[reply]

Next try :-) Thanks for your help! We've added book references instead if blogs this time. TBH: not adding knowledge from these blogs of well known authors will leave out the newest developments in the discipline. But I guess that's just the way it works, right? Henning Schwentner (talk) 14:16, 27 October 2021 (UTC)[reply]

Microsoft recommends it only...

Why is this relevant? Microsoft as an organization does not have per se neutral and best knowledge about software design, in fact history proves this is not the case. These days there is a community, which drives DDD implementation with CQRS and event sourcing. None of this is known to be Microsoft's home turf. FlorentBrianFoxcorner (talk) 15:07, 11 January 2024 (UTC)[reply]