views:

477

answers:

6

We are about to design a site for rentacar reservations using asp.net. There is a change that the application will scale up and I was wondering what if using DDD would help in maintenance and performance. I was wondering on what if there are new similar sites designed using datasets and SPs or DDD. So my friends to DDD or go old fashion ?

A: 

In my opinion, DDD is good for large websites that are built with ASP.NET MVC. However I caution that the ASP.NET MVC platform is still relatively immature at this time. If you choose to use DDD then I suggest you consider ASP.NET MVC, TDD and the Repository Pattern as your technology mix. If you're using standard WebForm I wouldn't suggest DDD. If you're using SPs then DDD really isn't great as you can't use the Repository pattern since it relies on GetAll, GetByID, Insert, Update, Delete ... and you extend these out with Filters implemented in LINQ using IQueryable ... well if you are using SPs then you have to cancel out the whole advantage of this structure. Just my view.

Nissan Fan
Actually i have little experience with nhibernate and its working great for me. I just wanna hear some thoughts on designing a new project that is expected to stand in time, will have good performance, scalability and will be easy on maintain. So I agree with Nissan Fan but I wanna share more thoughts on modern design.
George Statis
I think NHibernate is a very mature solution, however I've become extremely happy with the Entity Framework in conjunction with the Repository Pattern. This along with MVC, TDD is the pinacle of modern architecture on the .NET platform.
Nissan Fan
A: 

Yes it is possible to build sites that also perform well with DDD. The goal with DDD will be to let the domain be your driving model. Currently in our project we have used NHibernate as the Object Relational Mapper ontop of the domain. That is working very well, especially because NHibernate also supports different things to enhance performance like second-level cache. Lists of objects that need to be loaded from the database for 10000+ users only need one query and the different sessions will share the same memcache. So if you go with an ORM, make sure you make use of those cache-advantages!

What you should also consider is that for every release-cycle of your software you not only update the software (domain model) but also need to take care of updating the database when your domain model changes. However this is not different from having to update StoredProcs.

BTW: even when using DDD and an ORM, there will still be problems for which you might prefer to use SPs. Example: creating a new ordernumber. If 10000+ users are on your website and multilpe users want to create a new order, you have to make sure all ordernumbers stay unique. We found that we preferred SPs to do those kind of locking stuff above ORM.

If you now have the chance to try DDD definately have a go at it. Good luck.

Hace
A: 

As recommended by other readers, I can't recommend Greg Young and Udi Dahan's advice on Command/Query Separation enough.

pnschofield
+3  A: 

Like you, I'm in the process of creating a new project and I chose the DDD way which I'm sure is better then the "old fashion" way (decoupled and better testability)... But I have to admit that I'm struggling with some questions and can't always find the answers... even on stackoverflow.com

For example, the concept of aggregate root vs the design of an ASP.NET MVC website (master/detail relations - creating/updating) ; Model binding vs complex object graphs including entity objects and value objects, etc. All these are recent concepts and even the gurus (like Eric Evans for DDD) don't know all the answers.

Finally, I think that community projects S#arp Architecture are a very good place for learning, and asking questions.

W3Max
A: 

DDD is the only way if you want to be cool, sexy and get a higher contract rate!

alchemical
+2  A: 

"wondering what if using DDD would help in maintenance and performance."

A bunch of things can help with that. TDD/BDD, IoC, a good OR/M like NHibernate (w/FluentNHibernate for configuration)...

DDD, done right, is just one pillar in creating clean, simple and maintainable software. But it's only one piece of the puzzle. DDD can go horribly wrong if you just create a bunch of anemic domain objects with manager classes, use stored procedures for data access and forget about dependency injection...

But done right, what DDD can give you is clean and clear code: the procedural spaghetti code of the old west will go away and you'll find it easier to move around your own code base. Refactoring can take place (and becomes way less scary).

Personally - I would never touch another "old school" code base, and I certainly wouldn't start a new project that way. Give me a greenfield project and I'm going to ask for ReSharper, NHibernate, FluentNHibernate and StructureMap. And that's all I'll need....

Chris Holmes