Comparison
Service layervsTransaction script
Service layer
there is one method per use case, it opens the transaction, calls the model, and contains no business rules itself.
A boundary layer defining an application's operations as a set of use-case methods, coordinating transactions, security and the domain objects that do the work. It is what keeps controllers thin and what gives an application an API independent of its user interface. It is also the layer that quietly absorbs domain logic until the model beneath it is anaemic, which is the failure to watch for.
Full entry →Transaction script
one method reads the rows, does all the logic and writes them back, and it is four hundred lines long.
Organising business logic as a procedure per use case, working directly against the data. It is the honest right answer for a simple application, and it is what almost every codebase starts as; the failure comes later, when the tenth script needs the same discount rule and copies it. Fowler's original point stands: choose it deliberately for simple logic rather than arriving at it by default.
Full entry →