Timeline for Are DDD Aggregates really a good idea in a Web Application?
Current License: CC BY-SA 3.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Aug 10, 2016 at 14:57 | history | edited | CodesInChaos | CC BY-SA 3.0 | Replace broken link with a Wayback Machine link. |
| S Aug 10, 2016 at 14:57 | history | suggested | Stijn | CC BY-SA 3.0 | Replace broken link with a Wayback Machine link. |
| Aug 10, 2016 at 14:31 | review | Suggested edits | |||
| S Aug 10, 2016 at 14:57 | |||||
| Sep 4, 2015 at 13:06 | comment | added | Tuukka Haapaniemi | @Andrew Depends on whether the small value change is relevant to the business rules. If it is, then yes, you load the entire Entity to enforce the rules and fire subsequent events etc. If not, then it's a CRUD-operation where DDD is not required and the value propably doesn't even belong in the domain model in the first place. Remember to use the right tool for the job. DDD is not for everything and everywhere. That's what CQRS is about and separating the CRUD-operations as well. It's perfectly fine to use DDD for one bounded context and pure CRUD for another within the same application. | |
| Jul 11, 2015 at 9:43 | comment | added | Andrew | @qes Indeed, the best solution is to not use DDD for queries (read) :) But you still use DDD in Command part, i.e. for storing or updating data. So I have a question for you, do you always use Repositories with Entities when you need to update data in the DB? Lets say you need to change only one small value in the column (switch of some sort), do you still load whole Entity in the App layer, change one value (property) and then save whole Entity back into DB? A bit of overkill, too? | |
| Feb 16, 2011 at 22:37 | comment | added | quentin-starin | "I can't imagine that anyone would advocate returning entire aggregates of information when you don't need it." I'm trying to say that you are exactly correct with this statement. Do not retrieve an entire aggregate of information when you do not need it. This is the very core of CQRS applied to DDD. You don't need an aggregate to query. Get the data through a different mechanism, and then do that consistently. | |
| Feb 16, 2011 at 22:28 | comment | added | quentin-starin | class per query is an implementation detail. Acknowledging and accepting the fact that a domain model does not usually support queries well is more to the point. Besides, I don't always use one class per query, sometimes it makes sense to group a few related queries together. Also, I find a class per query is less boilerplate than mapping entities to DTO's - the only boilerplate I see is the same set of using's (filled in automatically when I create the class file) and an Execute method. The meat is usually a simple LINQ statement. | |
| Feb 16, 2011 at 21:50 | comment | added | Erik Funkenbusch | @qstarin- I disagree with the class per query approach for a lot of reasons. First, it creates a large amount of boilerplate code that you have to rewrite or copy (or generate). Second, it leads to an explosion of classes and I don't see how having 50 classes that do variations of the same thing are any better than 1 class with 50 methods. Even taking SRP into account, it seems to add complexity to the system as a whole. I think there's some middle ground, possibly with specifications that might be better. Also, one class per query makes it more difficult to substitute other persistence later. | |
| Feb 14, 2011 at 16:52 | comment | added | quentin-starin | Which is why we wouldn't use a Repository to read data in a CQRS system. We'd write a simple class to encapsulate a query (using whatever tech was convenient or needed, often straight ADO.Net or Linq2Sql or SubSonic fits well here), returning just (all) the data needed for the task at hand, to avoid dragging data through all the normal layers of a DDD Repository. We would only use a Repository to retrieve an Aggregate if we wanted to send a command to the domain. | |
| Feb 14, 2011 at 16:49 | comment | added | Erik Funkenbusch | I guess your familiarity with the subject allows you to infer meaning that my unfamiliarity does not. I don't see the the text you quoted as meaning the same thing you believe it does. "all the needed data" is not the same thing as "only the needed data". The way I see repositories working, they return all the data from the aggregate, not just the data you need. | |
| Feb 14, 2011 at 16:43 | comment | added | quentin-starin | Seriously, it's a central tenet of CQRS. What has to happen when we modify data is vastly different from what has to happen to read data, so CQRS (like CQS before it) aims to separate these concerns. The form CQRS often takes seeks to make this separation at a broad architectural level. Perhaps the CQRS Info page here on SO would help clarify for you what it is and is not: stackoverflow.com/tags/cqrs/info | |
| Feb 14, 2011 at 16:41 | comment | added | quentin-starin | @Mystere: I'm quite surprised you'd miss that if you read the article I linked to. See the section titled "Queries (reporting)": "When an application is requesting data ... this should be done in one single call to the Query layer and in return it will get one single DTO containing all the needed data. ... The reason for this is that data is normally queried many times more than domain behavior is being executed, so by optimizing this you will enhance the perceived performance of the system." | |
| Feb 14, 2011 at 16:36 | comment | added | Erik Funkenbusch | Can you provide any references that discuss that? The one you provided says nothing of the sort, and none of the other references i've found mention it either. | |
| Feb 14, 2011 at 14:32 | comment | added | quentin-starin | The purpose of the read side is to have exactly the data you need for each individual task, easy and efficiently available. Also, CQRS can be implemented with fully synchronous, in-process buses, so that eventual consistency doesn't really come into play. | |
| Feb 14, 2011 at 14:31 | comment | added | quentin-starin | @Mystere Man: No, it is for providing the minimal data needed. That's one of the large purposes of a separated read model. It also helps tackle some concurrency issues up front. CQRS has several benefits when applied to DDD. | |
| Feb 14, 2011 at 6:40 | comment | added | Erik Funkenbusch | So, after googling a bit on this, it doesn't seem that CQRS is intended to solve the problem i'm referring to. CQRS is about seperating command and query operations, and removing state. It seems more like CQRS is designed to solve various consistency problems, not providing the minimal data needed for an operation (which is basically what i'm discussing) | |
| Feb 14, 2011 at 6:21 | comment | added | Erik Funkenbusch | Interesting, I have not found mention of CQRS in any of the typical DDD sources... I'll look into it. | |
| Feb 14, 2011 at 1:02 | history | answered | quentin-starin | CC BY-SA 2.5 |