this really depends on the context. Scenario 1: No plans to add additional functionality. Sticking to the e-commerce example in the article, if I am designing

this really depends on the context. Scenario 1: No plans to add additional functionality. Sticking to the e-commerce example in the article, if I am designing a system for use by just one customer who wants to offer the discount for just that one scenario and they don’t have any future needs to offer any other kinds of discount then put logic in theDB. It’s quick and easy. Scenario 2: Plans to expand to add additional functionality. Sticking to the example we have future plans to offer other types of discounts to our customers. Which means we have to develop generic interfaces so it’s easy to add functionality. Have the business logic in the application layer. Scenario 3: plans to expand and additional functionality but also let users configure and add additional functionality without IT intervention. Sticking to the e-commerce example we want business users to create new offers and expose them to our customers. In this case use a rule engine like drools. It really depends on what functionality you are delivering and how you see that evolving in the future