http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 2026601) I would not, really. This is for a web app, which is most of what I do, the client is already assumed to be untrusted. 2) Depending on how I think about this. External interface can be a client for a service or it can be a part of a service. http://ayende.com/3444/default-architecture-layers#comment20http://ayende.com/3444/default-architecture-layers#comment20Mon, 01 Sep 2008 14:57:18 GMTThanks for the post. Couple of questions: 1) How would you alter the architecture for a partial trust interface (like XBAP / Silverlight) 2) How do you see SOA fitting into your architecture (is it just an external interface?) http://ayende.com/3444/default-architecture-layers#comment19http://ayende.com/3444/default-architecture-layers#comment19Mon, 01 Sep 2008 13:10:21 GMTI hope to be able to share one soon http://ayende.com/3444/default-architecture-layers#comment18http://ayende.com/3444/default-architecture-layers#comment18Tue, 19 Aug 2008 18:32:45 GMTDo you have a sample application using this architecture that you can share? http://ayende.com/3444/default-architecture-layers#comment17http://ayende.com/3444/default-architecture-layers#comment17Tue, 19 Aug 2008 18:31:00 GMTSokun, I would invoke validation in the controllers, but I would define it in the core http://ayende.com/3444/default-architecture-layers#comment16http://ayende.com/3444/default-architecture-layers#comment16Tue, 29 Jul 2008 13:30:57 GMTIn this architecture how do you deal with data validation? which layer would responsible for this task? http://ayende.com/3444/default-architecture-layers#comment15http://ayende.com/3444/default-architecture-layers#comment15Mon, 28 Jul 2008 15:04:39 GMT1) They serve the same purpose as controllers in MVC application. 2) They would not return DTO, because their function is not returning data, their function is to coordinate a use case. http://ayende.com/3444/default-architecture-layers#comment14http://ayende.com/3444/default-architecture-layers#comment14Sat, 26 Jul 2008 16:05:52 GMTAlright, so two questions: 1) Where would the controllers go and what would their function be? 2) Would your POCO application services map their input and output to DTOs? If not, what separates them from the domain services? Not to nitpick - might be missing something here... http://ayende.com/3444/default-architecture-layers#comment13http://ayende.com/3444/default-architecture-layers#comment13Sat, 26 Jul 2008 15:52:19 GMTWCF is an external interface layer. In my case, it would be: UI / WCF Application Services (POCO) http://ayende.com/3444/default-architecture-layers#comment12http://ayende.com/3444/default-architecture-layers#comment12Sat, 26 Jul 2008 08:52:53 GMTIt would be nice to have a concrete example of this - I'm a bit confused as to the role of the "controller" here. Here's the breakdown of the layers in a system I'm working on - maybe you could map it to yours? UI Application Services (WCF) Domain (Model / Services) Infrastructure (shared across layers as well) Here I'm using the term "application services" in the DDD sense as the externally facing layer that insulates the domain and is consumed by clients. (in my case multiple web UI's and other types of client applications who converse with the application services using DTOs) I might be using that term incorrectly, but that was my understanding based on the book. (obviously the choice to make that layer comprised of web services was my own as the system is distributed - I'm just using WCF for the sake of argument, insert your preferred technology here - nServiceBus, etc...) Within each application service I'm doing the same sorts of things as you describe within your controllers - transactions, etc... http://ayende.com/3444/default-architecture-layers#comment11http://ayende.com/3444/default-architecture-layers#comment11Sat, 26 Jul 2008 08:45:08 GMTNo, the application layer services are in the core. The controllers are the bridge between the external interface and the core, for a specific use case. For deployment scenario, probably, if I wanted to share them, but in general, sharing controllers is done when you have several endpoints that does much the same (imagine exposing the same behavior using different protocols) http://ayende.com/3444/default-architecture-layers#comment10http://ayende.com/3444/default-architecture-layers#comment10Fri, 25 Jul 2008 20:25:26 GMTLast test comment. http://ayende.com/3444/default-architecture-layers#comment9http://ayende.com/3444/default-architecture-layers#comment9Fri, 25 Jul 2008 19:56:52 GMT"While they can and should be shared if you are using the same use case in several external interfaces, note that this should not bleed into the controller itself" It sounds as though these are playing the role that Evans' application layer services are. Is this correct? If so, regarding a .NET project, given that you may have several different UI's, do you have your controllers in an separate assembly? I.e. one below the UI's which they can share? http://ayende.com/3444/default-architecture-layers#comment8http://ayende.com/3444/default-architecture-layers#comment8Fri, 25 Jul 2008 19:55:07 GMTI would love to see a "naked" sample system with this architecture that you just described. http://ayende.com/3444/default-architecture-layers#comment7http://ayende.com/3444/default-architecture-layers#comment7Fri, 25 Jul 2008 19:04:12 GMTI'm trying to understand the "external vs global context" you were talking about. Let's say I have some business objects "in memory", that I display in the UI. Does the UI manage those objects, or are those objects in the Core, that that UI references? From what you were saying, I think I can infer that the UI/Whatever external interface manages the "state" of the application, not the Core. The Core is stateless. Could you clarify? http://ayende.com/3444/default-architecture-layers#comment6http://ayende.com/3444/default-architecture-layers#comment6Fri, 25 Jul 2008 15:23:17 GMTTa for clarification, I've used a similiar style to what you are going for here but we were slightly looser about UI-model as we did allow some direct communication where what we were doing was simple (a single update to a single class in the model). http://ayende.com/3444/default-architecture-layers#comment5http://ayende.com/3444/default-architecture-layers#comment5Fri, 25 Jul 2008 11:54:30 GMTThere is variance per application, yes. The UI would only talk to the model as a way to display them. Setting properties would be the realm of the controller, in the specific use case. The UI tend not to talk to the service layer at all. http://ayende.com/3444/default-architecture-layers#comment4http://ayende.com/3444/default-architecture-layers#comment4Fri, 25 Jul 2008 11:46:00 GMTExcellent post, interested to know how strict you are on the layering. For example does the UI ever talk directly to the model and the models services, or does it always go through the services at the external interface? I guess you are varying that application by application? http://ayende.com/3444/default-architecture-layers#comment3http://ayende.com/3444/default-architecture-layers#comment3Fri, 25 Jul 2008 11:36:21 GMTFor me, yes. For other architectures, whatever it may be. http://ayende.com/3444/default-architecture-layers#comment2http://ayende.com/3444/default-architecture-layers#comment2Fri, 25 Jul 2008 11:15:50 GMTNice post. Are your services like those described in DDD? i.e. - things that don't naturally fit into the repository or entities? http://ayende.com/3444/default-architecture-layers#comment1http://ayende.com/3444/default-architecture-layers#comment1Fri, 25 Jul 2008 10:57:52 GMT