Attention: We are retiring the ASP.NET Community Blogs. Learn more >

Layered Architecture vs Living Domain Model

Ben Hogan has a an interesting post about the compatiblity between having a rich domain model and a layered architecture.

I agree with Jon Tirsen on this. It's not practical.

I also agree that a web application does not need a layered architecture. The problem is that if you want to reuse your domain model in a different scenario (like a rich client app) then you'll need the layered architecture, and your domain model will be pretty much useless, or it will require a significant refactoring.

 

6 Comments

  • I think you misunderstood the gist of the post. What he was saying is that you may not need a "Service Layer". Layered architecture is a good thing. I also don't understand your statement regarding the fact that if "your domain model will pretty much be useless" if you switch to a layered architecture.

  • I agree layered architecture is a good thing. I don't think a domain model is a good thing.



    For example, if you have a web app you can put all the validations inside your domain model and expect them to be triggered at the right time. If you build a win app that uses webservices to talk to your middle tier you'll need those validations at the domain model and also in the win app layer. So you'll need to refactor your code so you can use the same validation code in both places.



  • I mean, refactoring your code to reuse your validation code in both places is moving away from the 'smalltak way'.

  • Or maybe you should simply duplicate some logic specially targeted for the smart client(a kind of optimization), instead of adding a thick non-transparent layer between the domain model and the inproc web app, which will kill you. As if the same is not being done currently with web apps and jscript in order to get better responsiveness ...

  • I understand what you're saying, but I still think it can be accomplished within the domain model. Validators can be created for each rule this can be implemented in a controller class with methods on the controller class for realizing them in an interface. These rules for these Validators could ultimately reside in the domain model itself.



    I know...very vague. I'll see if I can't demo up a quick implementation

  • You don't need to. I understand what you mean.



    My point is that's not the way you'd build your domain model if you were not thinking in layering it, and it adds complexity to it. Is much easier to validate in the domain objects themselves.



    So, how you can make that decision? Or you start thinking it will live in different tiers and design it with that in mind, adding complexity (the kind of complexity I think Jon Tirsen was referring to), or you build it the 'smalltalk way' and you can use it just from one layer.

Comments have been disabled for this content.