I think that the underlying concept behind business logic is “ separate what is important from what is not “
Something like:
If you mix pagination logic with listing customer you end up with code that is hard to maintain, and it is rigid, changing pagination will affect the listing.
It would be better if you define a piece of code that takes care of listing customer data and another that paginate a list of objects.
So following this separation of concerns idea you can apply it to state:
Separate all what describes the business (interactions between stakeholders and your system) from the rest of your code.
When a business rule change you don’t need to scan 100k lines of code to know what needs to change because you separated these rules you know where to find them, they are not duplicated in many parts of your system, so you only need to change one place.
Also business rules change often, so business logic should be easy to change. We can get that benefit by programming based on a set of small objects with single responsibility. ( business objects or domain objects)
Usually these objects arise from refactoring existing code in the search for recognizing underlying abstractions.
This idea sounds pretty cool but unfortunately based on my experience software developers do not invest time to recognize and separate the business logic, we just write code inside some part of the framework and we end up with a mess.
I know that lots of programmers share this question, so thanks for asking.
Hope this help!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think that the underlying concept behind business logic is “ separate what is important from what is not “
Something like:
If you mix pagination logic with listing customer you end up with code that is hard to maintain, and it is rigid, changing pagination will affect the listing.
It would be better if you define a piece of code that takes care of listing customer data and another that paginate a list of objects.
So following this separation of concerns idea you can apply it to state:
Separate all what describes the business (interactions between stakeholders and your system) from the rest of your code.
When a business rule change you don’t need to scan 100k lines of code to know what needs to change because you separated these rules you know where to find them, they are not duplicated in many parts of your system, so you only need to change one place.
Also business rules change often, so business logic should be easy to change. We can get that benefit by programming based on a set of small objects with single responsibility. ( business objects or domain objects)
Usually these objects arise from refactoring existing code in the search for recognizing underlying abstractions.
This idea sounds pretty cool but unfortunately based on my experience software developers do not invest time to recognize and separate the business logic, we just write code inside some part of the framework and we end up with a mess.
I know that lots of programmers share this question, so thanks for asking.
Hope this help!