Transaction script is Antipattern?

Question

Well there is a similar topic about transaction script with NoSQL database, but this one is about the pattern in general. From what I find about Transaction script, it is not object-oriented at all. Its basically procedural code despite the fact that it may use objects in every line of its code.

The better solution is to use a domain model instead, coupled with either active record or a data mapper with unit of work/identity map/lazy load/query object and such. Transaction script may be easy to use, but it is really procedural programming and therefore should be considered an antipattern in object oriented world.

What do you think? Do you agree with transaction script being antipattern? Or do you actually have a way of designing a transaction script that is object oriented instead of procedural in disguise? I doubt this is possible though.

Answer 1

Transaction Script is definitely not an anti-pattern.

From what I find about Transaction script, it is not object-oriented at all.

You are right, it is not, indeed. That fact however doesn't make it an anti-pattern. Although it is a procedural approach, indeed, it still has its right place in the series of business logic architecture patterns - you just have to know in which case it is a best practice to use it - and in which case it isn't. Simply put: if your problem domain is very simple then it isn't worth the overhead to use a more complex pattern in your business logic.

Or - as Fowler writes:

When to Use It

The glory of Transaction Script is its simplicity. Organizing logic this way is natural for applications with only a small amount of logic, and it involves very little overhead either in performance or in understanding.

The anti-pattern you might think about is called Anemic Domain Model. This is the case when you intend and think you are building a Domain Model - because your problem domain is complex enough for that, - but you actually end up in a Transaction Script - because of bad code organizing / weak OO skills.

Answer 2

It's not an anti-pattern. In fact, most enterprise applications (all I have seen) use transaction script and not a rich domain model pattern.

Active record pattern you mentioned is only handy when you have rather simple one to one mapping of domain entities to persistent store aggregates (RDBMS tables).

Data mapper is something like ORM (Hibernate and friends). If your business logic resides within domain entities, these entities must mutate themselves. In my opinion, this couples logic which mutates state (which is inherent when you use ORM) with the state itself. It's simpler to look at your domain model from outside and put your business logic into services (transaction scripts). Also, if your business logic volume is large, it's harder to find relevant code when it's scattered across domain entities (it's like having your transaction scripts mixed together).

But you don't have to end up with completely procedural approach since you can (and should) decompose your services into self-contained highly cohesive 'procedural containers'.