We cannot think of an Active Directory without group policies. Using group policies, we can apply rules to manage application settings, security settings, and system settings of Active Directory objects. Each and every object in Active Directory has different operation and security requirements. As an example, sales computer security requirements are different from a server that hosts the database system. Group policies can be bound to the organizational units. Therefore, objects that have different Group Policy requirements can be placed into different OUs with relevant policy settings added. Even though this is the most common reason for OUs, this is where things mostly go wrong as well. If you do not consider Group Policy inheritance and how parent Group Policy settings will affect group policies in child OUs, eventually, you can end up with Group Policy conflicts or not applying policies:

In the preceding example, the structure has a default policy, which applies to the majority of the objects in the AD structure. Therefore, it is created at the top of the hierarchy. It is inherited to the child OU levels by default. Therefore, Sales department and Users under Sales department will have the default policy inherited by default. But the organization would like to add specific sales user settings via a Group Policy. For that, a new Group Policy is created with the name Sales user policy and is mapped to the Users OU of Sales department. By default, the Computers OU under Sales department will also have inherited default policy, but due to operational requirements, it should block that policy and should have only Sales computer policy, which is linked to the Computers OU. In order to do that, OU inheritance is blocked. It will no longer apply any inherited policy from parents OUs and only apply the policies that are linked to the OU. This explains how we can use OUs to facilitate Group Policy requirements.

Before we implement the OU structure, we need to decide why we need each of these OUs. This needs to be evaluated based on the preceding three points; if the requirement does not fall under these three points, we should not set up an OU. Most engineers do not pay attention to designing the OU structure because OU structures are easy to change compared to domain structures. If the OU structure does not match your needs, it can be replaced with a completely new structure. But it is followed by moving objects and the Group Policy hierarchy restructure. Even though OUs have flexibility to adopt structure changes, it's important to get the initial requirements correct and design a structure with improved manageability and extensibility in mind.