- a persistence/data layer, to store raw data. Often implemented as queries on a database;
- a business logic layer, to manipulate the 'objects' according to certain rules;
- a presentation layer, to present information to the user and to allow interaction.
Mixing these might give you headaches later on, but that is for another time.
Some business rules may rely on certain conditions or values to be met. For instance, if the order total is over $100.00, get approval from a sales person before sending it off to the warehouse. Or: if this is one of our Gold Customers, offer a special discount. As software is used in more and more complex environments, the complexity of the business rules (naturally) increases.
There is an ancient rule of software engineering: don't hard code anything. Hard Coding means that you put variable information in the source code, thereby embedding it 'hard' into the program. An example is a database connection string: if the application has to be deployed to another environment, the source code would have to be changed in order to use a different database! Clearly, stuff like that should be in configuration files.
In today's Worse Than Failure article, a new term is launched: 'Soft Coding'.
Soft Coding is using configuration files to change the behaviour of the program. For instance, the order amount limit mentioned above could be put in a configuration file, and the program could check the order amount against the amount in the config to see if a particular condition is met! When the limit is changed, all you have to do is edit the config file, and you're done!
However, with more and more complexity in the business layer, the settings become more and more complex. If you're not careful, you (re-)create something Alex calls 'The Enterprise Rules Engine' -- basically a programming language within the program to tweak the behaviour of the program.
Soft Coding leads to even more headaches than Hard Coding, because you add an extra layer of complexity to something that's already complex. Software is meant to make things easier!
Also, it's software -- it can be changed! So if a business rule changes, you can simply change the source code that implements that rule, recompile and redeploy, and be done with it! That is what the business logic layer is for!