http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Josh, There was never any complex enough query in RaccoonBlog to warrant that.http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment47http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment47Sun, 26 Feb 2012 07:18:31 GMTI'd really like to see how queries are structured. Is there an example somewhere in Racoonblog?http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment46http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment46Sun, 26 Feb 2012 02:26:44 GMTThe key to DDD is the *analysis.* a) Does *this* application need to interact with other applications? b) Will users of *this* application work on the same data at the same time? c) And most importantly, how much *time* do we have? Maybe I didn't look hard enough, but I couldn't find a) or b) anywhere in the sample application. Which is funny because The Blue Book talks about these in its example cargo sample application: Notifying billing once a cargo has reached a destination and maximizing cargo allocation on a voyage. *This* is where the competitive advantage lies and where the most time should be spent. Not in *booking* the cargo.http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment45http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment45Thu, 23 Feb 2012 01:18:08 GMT@Simon, I second your wish here :)http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment44http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment44Thu, 23 Feb 2012 00:24:02 GMTFalhar, If your entire app is a single bounded context, there is something wrong in your apps.http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment43http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment43Wed, 22 Feb 2012 09:19:45 GMT@Ayende, interesting way to look at it. Thanks for your thoughts. Damn, I wish I could afford to pay you to pair with me for a week!! :-)http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment42http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment42Wed, 22 Feb 2012 09:06:56 GMT@Ayende: The key point heres is, that whole NDDD sample is only one bounded context. So either use DDD or don't. Picking parts where DDD is too complex and only "fix" those is bad example.http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment41http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment41Wed, 22 Feb 2012 07:55:55 GMTSimon, In that case, I have two apps, not a single app. One is the actual app that communicate via WCF / REST / whatever. The other is the web application whose backend are the services. http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment40http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment40Wed, 22 Feb 2012 02:56:14 GMTSteve, The case for multiple commands is RARE, and should be avoided. It usually means that you aren't encapsulating at the right level. The case for multiple queries is more common, but should be limited to 2 - 3 due to performance and complexity issues.http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment39http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment39Wed, 22 Feb 2012 02:54:54 GMT@Juanma it probably isn't too different to a service to be honest. But at least you force a class to only have one responsibility. Service classes have a tendency to break that and become god classes. http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment38http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment38Tue, 21 Feb 2012 23:20:10 GMTThanks for the reply Ayende. I agree with what you are saying about CommandHandler. I was going to write about the fact it makes sense in a message based system. In a single app I guess the only advantage it offers is to prevent 'junior' devs calling Execute in the wrong places. But I guess code reviews and education can solve that problem too! Would it make sense if you thought the app might need to a separate business layer though? (think typical 'enterprise' n-tier system; often you are forced into this as web layer has no access to database for example). Or do you YAGNI that and refactor when needed? http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment37http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment37Tue, 21 Feb 2012 23:15:27 GMTAyende, what are your thoughts on cases when a command/query needs to call multiple commands/queries? Do you believe this logic should only exist in the controller, even if this logic needs to be reused elsewhere?http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment36http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment36Tue, 21 Feb 2012 22:06:39 GMTFrank, That is something that I would do if there is the need to distribute the work. If this is happening in a single machine, there is no real need to do that. It is simpler to just have a command.http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment35http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment35Tue, 21 Feb 2012 21:52:35 GMTFalhar, > You can't use DDD in one part of the application and not use it in another one. HUH?! What on earth gave you that idea? This is what bounded contexts are ALL about. http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment34http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment34Tue, 21 Feb 2012 21:51:05 GMTBob, Yes, exactly!http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment33http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment33Tue, 21 Feb 2012 21:49:21 GMTSimon, I really don't like the CommandHandler{T} issue. This is really annoying and means that we have to modify things in two places at once. This is only useful for things like messages and message consumers. But on the same app? Just use a single class.http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment32http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment32Tue, 21 Feb 2012 21:48:52 GMTMatthew, Based on whatever make sense at the moment.http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment31http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment31Tue, 21 Feb 2012 21:47:11 GMTJuanma, Take a look at the InjectProperties() method here: http://www.jeremyskinner.co.uk/2008/11/08/dependency-injection-with-aspnet-mvc-action-filters/ You can then just call: kernel.InjectProperties(command); command.Execute();http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment30http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment30Tue, 21 Feb 2012 21:46:29 GMT@Falhar: I think this idea that one could be writing a CRUD app and suddenly realize they need it to be a DDD app belongs on the same shelf where the idea that you use the repository pattern because you may want to replace your ORM was tossed. If you are 1/2 or 1/4 of the way through your project and only then do you discover that your project is important AND complex enough to require full on DDD you are already failing miserably. http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment29http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment29Tue, 21 Feb 2012 20:03:01 GMT@Ryan: Then how do you decide when to use DDD and when normal CRUD? From your point, If I write it as DDD, I introduce lots of overhead. But if I write it as CRUD, it might be too late to move to DDD, because the logic is already there and changing it is too much work. I believe you can make clean DDD infrastructure so simple, that it still remains DDD, but will not introduce much development overhead.http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment28http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment28Tue, 21 Feb 2012 19:17:22 GMTWould anyone be so kind as to add a draft implementation of the base Command object on somewhere like pastebin? I'm interested in seeing how the someone else would implement it's Query() method as opposed to the extremely naive implementation I'm playing around with. Many thanks!http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment27http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment27Tue, 21 Feb 2012 18:52:13 GMTWhat Frank said. I would prefer to see a separation of the Command and the Handler. Mainly because I think you have two different concerns... The creation of the command parameters, and the creation of the command dependencies. You can place the handlers all in one file. With multiple execute methods each taking a different kind of message. In a sense is is what WCF does, although it tries to abstract this so it appears as RPC and just overall complicates life. Either way what is nice about this approach is that system maintenance largely becomes append only, and there are a wide number of additional ways to easily extend the system thru command composition.http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment26http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment26Tue, 21 Feb 2012 18:08:52 GMT@Falhar- Because DDD comes with a fair amount of overhead (in infrastructure, time spent talking to end users, and a learning curve) it should only be used in those parts of an application that give your company a competitive advantage in your industry. That probably means that 95+% of your LOB apps are probably going to end up CRUD and that one or two mission critical system(s) will have a lot more thought going into them. And only then if the complexity warrants it. You can do a whole lot without DDD.http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment25http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment25Tue, 21 Feb 2012 17:22:07 GMTAyende, what about treating the command as a message (I.e. command in the sense of an order) and having the infrastructure dispatch the command to the piece that handles it? Resharper discoverability is given and you have another set of ways to slice and dice the stuff that does the work, e.g. Putting related execution paths into one class. Or do you think the mental overhead of 1:n publishing isnt worth it for the situations you describe?http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment24http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment24Tue, 21 Feb 2012 17:01:31 GMT@Juanma Like Ayende said, "It may decide to use a container." If you're using an IoC there should be a BuildUp function to inject properties on that command.http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment23http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment23Tue, 21 Feb 2012 16:35:22 GMTIt is possible to organize commands by domain behavior (use case), say "CargoTracking", rather than the broader domain object "Cargo". That would make commands easy to find. For example, "CargoTracking.Commands.RegisterCargo" Here I am suggesting namespaces but your commands could be defined within your controller, if they are controller-specific but I suppose you would not have that many commands on a controller that would lead to confusion and unorganized code.http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment22http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment22Tue, 21 Feb 2012 16:27:03 GMT@Falhar: I think the argument can be (and was previously) made that NHibernate or whatever ORM **is** the generic Repository; there's no need to create another abstraction over it just to put the word "Repository" there.http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment21http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment21Tue, 21 Feb 2012 16:13:12 GMTAlso one thing, that everyone is forgetting here: DDD is about change. Constant change. Ayende is refactoring already existing code, without zero changes in between. I believe this kind of code is too hard to change and modify. While YAGNI still aplies, DDD tries to make changes managable, so you dont have to worry about that.http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment20http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment20Tue, 21 Feb 2012 16:13:03 GMT@Simon, So basically, you are changing service methods for command handlers? I like that approach and actually I do use it a lot, but I can't see how different is that from the point of view of abstractions. When your handlers began to depend on IEmailSender, ICreditCardChecker and so on, aren't you back with a lot single-use interfaces? You have just pushed the services one layer below, from controllers to command handlers.http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment19http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment19Tue, 21 Feb 2012 16:12:52 GMT@Wayne: DDD is not about how to abstract things. DDD is about how to make business changes easy, because you know where and how to put them into existing code. And creation and persistence of entities is important part of that. And like someone said in comments to previous post. You can't use DDD in one part of the application and not use it in another one. You either use DDD across your whole business logic (thus introducing Repositories and Factories, that only do call-through) or you don't use DDD and freely mix business and persistence logic, but you loose way to comunicate those changes with business people. And obviously, this example is to show rather simple Domain Model, but it is still a Domain Model. And ignoring this fact can simply turn that domain model into CRUD application. I'm not saying to create interface and implementation of concrete repository for each agregate root entity. But having single generic repository is enough to handle all the persistence abstraction for whole DDD.http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment18http://ayende.com/154241/limit-your-abstractions-the-key-is-in-the-infrastructure#comment18Tue, 21 Feb 2012 16:05:23 GMT