Typical .NET DDD architecture vs Django/Rails practices

Question

I've accustomed to all typical domain driven design practices that are prevalent in most of publications and blogs concerned with modern .net programming. It surprised me, hence, that when I spoke with some Django folks they didn't care about persistance ignorance, viewmodels etc.

Lack of persistance ignorance part may seem understandable when you use Active Record in Django or Rails, neverthelsess using domain entities in views looks like pure evil after having worked a bit in ASP.NET MVC land (same with Java mvc frameworks, I guess).

It's not a single case, it pertains to an overwhelming majority of Django/Rails projects (which always were perceived as Überagile).

Why is that? Is it just because of dynamic language features which make practices like DI unnecessary? Or maybe there's to much overengineering in a enterprisy .NET/Java world?

Do you know of any more architectural differences? Are there any lessons to be learned for .net/java world or, on the contrary, is it just that rubist and pythonistas haven't usually worked with big enough projects to understand the advantages of those patterns?

Answer 1

Nice, a lot of discussion already. Here's my opinion on the matter:

Usually it's far easier to access the domain model straight for your forms. It's one of those things that give coding in Rails (I don't know Django, but I'm guessing it's the same) a huge productivity boost. There is hardly any coding need: have a database table, build some html and a simple controller in the middle and you're done. Because there is hardly any code involved, you can change faster, that's why it works well in Agile environments.

But, there is a time when this falls short. Sometimes, your application is too complex to make this work properly. That's when you can add ViewModels, Presenters, Facades, or whatever you want to call them. There is nothing stopping you from doing this in Rails or Django. In fact, Rails 3 introduced ActiveModel as a set of mixins to make every object work as easy with forms as when dealing with ActiveRecord.

So the question isn't why are Rails and Django not doing it, but when should I use it? Calling DDD overengineering isn't true either. It's about doing "just enough" to solve the problem that you have. Keep the amount of code and complexity as low as possible, and you will be easier to maintain.

I would agree that there are certainly lessons to be learned from Java/.NET. Usually they have gotten the design pattern thing worked out nicely. But saying that Rubyists and Pythonistas didn't do enough big projects is not true. The power comes in recognizing when you can get away with a simple solution.

I do think Java programmers (I have no experience with .NET programmers) tend to overengineer things. Maybe it's the frameworks they use. It seems to try to force the programmer to do it "The Right Way", thus making it overly complex.

Answer 2

Perhaps this is your opportunity to explain the advantages of a viewmodel, as I personally see it as a complete waste of time and space. While most of my MVC work has been in Rails, I'm currently working in Spring and have so far always interacted directly with the models stored in my relational database.

If you intend to make certain attributes of a model inaccessible, then don't expose them. You can give them further protection in your before_save method or elsewhere if you wish, but is that even necessary, given the likelihood that a user knows the names of the attributes that you've chosen not to expose?

If there are some other reasons why a viewmodel is beneficial, then I'm all ears (or eyes, as the case may be).