We were taught that objects are self contained things with data and behaviour and therefore they should have methods that act on their attributes. But there are several situations when this coupling between entities and their behaviour is not observed:Entity frameworks (like .NET with POCO and Enterprise Java with POJO entities) stipulate that CRUD/persistence/search operations should be done by external entity managers (and repositories) and not by the entities themselves, i.e. we have code entityManager.save(entity) and not entity.save();Business rule engines are the most visible examples of separating business logic from the entities - business rules form completely different code (even in different languages) from entities. E.g. JBoss Drools or IBM ILOG or other rule engines. Business rule paradigm can be used for the extrapolation of OO programming - in OO we consider data and methods, but in semantic web we can consider ontologies and logical/business rules that are acting on the ABox or TBox of ontologies - two completely different languages and reasoning systems.Distributed computing stipulates use of serialization and deserialization of objects and communication of those objects across network - we have XML, native binary formats or JSON for this. Usually only data are communicated over network and business logic is kept in one layer and there is not technology for moving business logic across network and platforms, e.g. there is no automatic translation and communication of business logic when Java entities are translated into JSON objects and exposed through REST API to Angular 2 frontend. Business logic usually is kept in one side (e.g. in Java).  It is said that OO domain model should reflect/model real world. And sometimes the real world objects do not have business logic inside them. E.g. there are concepts about calculators, e.g. tax calculators, salary calculators etc. Therefore we write calculator.recalcTaxes(invoice) and not invoice.recalcTaxes. The former approach allow us to apply different calculators in different cases = e.g. across legislations. We are not forced to build complex inheritance hierarchy simply beacuse there are different business methods, we simply apply different business services/calculators to the same data.Considering those arguments pro separating business logic from data/entities - how acceptable is to make this separation as the general rule of design for my project of business software? What are the arguments against separating business logic from data?
How acceptable is to keep business logic outside entities (in separate service classes)?
design patterns;object oriented design;business logic;business rules;distributed system