Question: The new place I started at is just starting to develop a completely new product from scratch. They are going transaction script in application services, completely dumb entities, and a hand rolled DAL with stored procedures (the argument is that nhibernate doesn't optimize sql well, loads too much stuff, doesn't scale well to huge projects etc etc etc). the app is supposed to be HUGE project just in it's infancy.

I'm coming from a position where I was doing domain model with all business logic encapsulated in that and the app services only handling infrastructure + loading up the model with nhibernate and scripting it.

I really believe going with the 2nd approach is much better. I was planning on doing a presentation on why. I have plenty of books/articles/personal opinions that I can back this up with...but being more of a "junior" there it might not mean much (I was also the single dev at my last place).

What I'm looking for is some experience/tips/examples of failed projects from more senior people why going transaction script/hand rolled DAL is not the right idea.

Answer: 
In addition to what [Paul T Davies](https://stackoverflow.com/questions/7563200/from-domain-model-to-transaction-script/7568190#7568190) and [Magnus Backeus](https://stackoverflow.com/questions/7563200/from-domain-model-to-transaction-script/7566625#7566625) have said. I think that at the end of the day it would be a people and cultural issue. If people are open minded and willing to learn it will be relatively easy to convince them. If they consider you a 'junior' (which is a bad sign because the only thing that matters is what you say not how old/experienced you are) you can appeal to a 'higher authority':

* [Patterns of Enterprise Application Architecture](https://rads.stackoverflow.com/amzn/click/com/0321127420)
* [Domain-Driven Design](https://rads.stackoverflow.com/amzn/click/com/0321125215)
* [Growing Object Oriented Software](https://rads.stackoverflow.com/amzn/click/com/0321503627)
* [Dependency Injection in .NET](https://rads.stackoverflow.com/amzn/click/com/1935182501)

Stored procedures are dead and you are not the [only one who thinks so](http://www.thoughtworks.com/articles/technology-radar-july-2011):

> 
> It is startling to us that we continue to find new systems in 2011
> that implement significant business logic in stored procedures.
> Programming languages commonly used to implement stored procedures
> lack expressiveness, are difficult to test, and discourage clean
> modular design. You should only consider stored procedures executing
> within the database engine in exceptional circumstances, where there
> is a proven performance issue.
> 
> 
> 

There is no point in convincing people that are not willing to improve and learn. Even if you manage to win one argument and squeeze in NHibernate, for example, they may end up writing the same tightly coupled, untestable, data-or-linq-oriented code as they did before. DDD is hard and it will require changing a lot of assumptions, hurt egos etc. Depending on the size of the company it may be a constant battle that is not worth starting.

[Driving Technical Change](https://rads.stackoverflow.com/amzn/click/com/1934356603) is the book that might help you to deal with these issues. It includes several behavior stereotypes that you may encounter:

* The Uninformed
* The Herd
* The Cynic
* The Burned
* The Time Crunched
* The Boss
* The Irrational

Good luck!
I would say taking material to back it up is the way to go, that way they can't use your inexperience as an argument (although it sounds to me that you are not particularly inexperienced or junior!). My main reccomendation would be this book:

<http://www.amazon.co.uk/Microsoft-NET-Architecting-Applications-PRO-Developer/dp/073562609X/ref=sr_1_1?ie=UTF8&qid=1317121019&sr=8-1>

On page 146, it states: 

'TS is suited for simple scenarios where the business logic is straightforward and, better yet, not likely to change and evolve.'

This does not describe the system you are working on. 

It then goes on to describe Domain Model, and why it is suited to bigger systems.

I would question whether thay understand that it is Transaction Script they are opting for? In my experience, TS can often be the default choice for inexperienced organisations who don't even understand that there is even an option. They just think 'that's how it's done'. How successful and maintainable is their current code? If they are choosing TS for huge projects, my guess would be 'not very'! Do they blame the client for changing specifications when things go wrong? If so, this is an indication that their choice of architecture is wrong.

In my experience, the overhead in implementing Domain Model is minimal. And it is a lot less painful than trying to scale and maintain a badly architected system.

Also, in this day and age, database servers should be able to handle systems based around NHibernate with no problems. If it can't, then that is a problem with the database server. And how do they intend to unit test these stored procedures? I usually find SP are the single biggest point of developer error.

Like Magnus said, I could just go on and on about this. I don't know the details of the system, but as soon as you used the word HUGE, Domain Model becomes the most obvious choice.