If the business rules change, only the business services components that contain those rules will need to be changed. If the business rules are placed within the user services components, the user services components will have to be updated every time a rule changes. If such a user services component were an .EXE application installed on thousands of computers, a change in the business rules would mean reinstalling the component on all the client computers.
Separating the business rules from the user services components is only one benefit of using business services components. Business services components usually contain logic that is highly reusable. For example, if you create a business services component to retrieve product information for a Windows-based application, you don't need to rewrite this component if you want to create a Web-based application that requires the same business logic.
Using business services components also simplifies the building of your user services components. As previously mentioned, the business rules in the three-tier model are moved from the user services components to the business services components. Thus, the user services components are simplified. In addition, if you build business services components as objects that expose methods and properties, your user services components can be simplified further since the code in your user services components will consist of setting properties and calling methods of the business services objects.
For example, let's say your application requires validation of new orders. You can implement the validation logic in the user services components, but you can also separate this logic from the user services components and implement it in an Update method in the business services components. Thus, the validation of a new order will be done when you call the Update method.