Calculated fields in Laravel and general PHP -

in laravel / php easy create accessors , mutators transform or create dynamic fields database.

although easy duplicate same logic throughout app, when not accessing same data through orm model (e.g. direct queries).

$order->totalplustax; // (total * 10%)

the logic calculate field should written once, testable , not tied orm.

what best practices or design patterns around logic?

design patterns have evolved way organise , provide performance gains our code. address specific issues. question broad design pattern solve degree.

for example, if have logic checks database conditions before creating object, live in objects factory class , else. if have logic finds object checking conditions in database, logic live in repository class , else.

the solution problem isn't 1 particular design pattern. solved many design patterns, oo classes , methods, , following solid principles.

side note:

i'm sorry if not answer expecting. found myself in similar position few years ago when started studying design patterns , community best practices.

the issue think have coders apply our logical minds literally everything. when looking design patterns , best practices spend days trying work out correct way implement something. answer not design patterns or community best practices. answer is:

the correct code write code makes test pass, test validates value being delivered business.

i'm not saying write old code, dont know design patterns use until start writing code. best place start write code makes application work: kent beck's advise on this:

make work, make right, make fast.

the "make right" part refactor code out design patterns etc. need @ code base , see there common elements. case of refactoring out common logic class or method. use design patterns have mentioned.

obviously there times when have pretty idea of end solution , can use design patterns front (active record, mvc etc) in case seems know once start seeing duplicate logic. i'm afraid case of looking @ few design patterns , seeing if work you, refactor common code out separate class or method. community best practice looking for.