OO Design / Patterns - Fat Model Vs Transaction Script?

Question

Ok, 'Fat' Model and Transaction Script both solve design problems associated with where to keep business logic. I've done some research and popular thought says having all business logic encapsulated within the model is the way to go (mainly since Transaction Script can become really complex and often results in code duplication). However, how does this work if I want to use the TDG of a second Model in my business logic? Surely Transaction Script presents a neater, less coupled solution than using one Model inside the business logic of another?

A practical example...

I have two classes: User & Alert. When pushing User instances to the database (eg, creating new user accounts), there is a business rule that requires inserting some default Alerts records too (eg, a default 'welcome to the system' message etc). I see two options here:

1) Add this rule as a User method, and in the process create a dependency between User and Alert (or, at least, Alert's Table Data Gateway).

2) Use a Transaction Script, which avoids the dependency between models. (Also, means the business logic is kept in a 'neutral' class & easily accessible by Alert. That probably isn't too important here, though).

User takes responsibility for it's own validation etc, however, but because we're talking about a business rule involving two Models, Transaction Script seems like a better choice to me. Anyone spot flaws with this approach?

Answer 1

consider moving some of the business logic into the service layer

Answer 2

For simple apps with little business logic, use Transaction Script. It's straight-forward (since each script typically maps with a software use case) and easy to implement (for example, you won't have to deal with complex OR mapping as in the case of rich domain model). In fact, spending much time on crafting a rich OO model for simple apps is, to me, an act of over-engineering.

For more complex apps (or when the previously simple apps become more complex), you'll almost certainly see the pitfalls of the Transcription Script pattern emerge, namely code duplication and rigidity in the transaction scripts (which by now might have become big balls of mud). In this case, a rich domain layer would make more sense.

Generally, I would start building apps using Transaction Script and slowly refactor it toward a richer domain model when the app grows.