The domain is what you are modelling. If you are modelling a business problem, they are the same thing. If you are modelling something else, physics for instance, there is probably no business logic in your system, but the physics parts are still domain logic.
Generally a Spring service is transactional. Things go into a particular service method because they ought to be grouped together in the same transaction. If you want to retrieve an object from the database, twiddle it, and save the new version, the retrieval and save ought to be in the same service method. So your … Read more
I prefer to put domain logic in the model for a couple of reasons. The model should have no UI code in it and thus be easier to test. Whenever possible, I like to have a fully working (meaning complete test coverage) model before writing any UI code. The controller can trust that the model … Read more
Business logic should really be in the model. You should be aiming for fat models, skinny controllers. For example, instead of having: public interface IOrderService{ int CalculateTotal(Order order); } I would rather have: public class Order{ int CalculateTotal(ITaxService service){…} } This assumes that tax is calculate by an external service, and requires your model to … Read more
Fist of all: I believe that you are mixing up the MVC pattern and n-tier-based design principles. Using an MVC approach does not mean that you shouldn’t layer your application. It might help if you see MVC more like an extension of the presentation layer. If you put non-presentation code inside the MVC pattern you … Read more