The whole purpose of the sharing model is to ensure the correct users access the right records at the right time. This is an expansive subject and understanding this well is one of the critical pieces to getting the most out of the platform. Not understanding it, you risk reinventing the wheel programmatically, and inevitably causing yourself and others headaches down the line.
First of all sharing works in conjunction with your profile CRUD settings. So without the correct profile setting, you won't access the object/entity in the first place. Let's say our user has create-read-edit-delete access on their profile.
Sharing begins with record ownership. Unless you are the record owner, you cannot delete, share, or transfer ownership of the record. So even if your CRUD profile setting says "Delete", unless you are the owner, you can't delete anyway.
Next your organization-wide default (OWD) sharing settings for an object. This sets the basic access for all other non-owner users. The most access (and default for custom objects) is public read/write, which gives all users the ability to read and edit all records of that entity, but doesn't include delete. Next is public read-only, which gives all users the ability to read records, but no edit perms. Finally there is private which means that unless you are the owner...or you are given access through some other means (wait for it...) you have no access to records.
OWD's are the only way to remove access to records. Everything else that follows is about giving access to records.
Next we have roles. Roles are a hierarchical scheme that allow some users to inherit access to records based on other users below them in the hierarchy. If I sit above a user in the hierarchy, I will inherit that user's access to a record. So if a user below me is an owner...I have ownership permissions. If a user below me has read-only access...I have read-only access...etc.
Territories also exist similarly to roles but have widespread ramifications and are only turned on in some orgs. The fundamental difference is that roles are single-inheritance and that territories allow multiple inheritance. Until Spring 14, once territories are turned on, they cannot be turned off again.
Next we have sharing rules whereby we can share a record with a role, a role and all of the roles below that role (roles and subordinates), or a public group (different from a Chatter group).
Sharing can also be performed one-off by a user.
Sharing can also be performed with Apex in Apex managed sharing.
Finally, no matter your record/sharing access, field security will still be enforced for the user's profile. So whether or not I'm the owner, if my profile denies me access to a certain field, I can't access that field.
I have not had to go through the process first-hand of setting these things up in an org, but I can say that orgs that do not plan this out typically have headaches and problems. But this is the fundamental architecture in the platform to ensure user-to-record access and security.
Here are some links to resources to read up on these:
Overview of Security wiki: https://trailhead.salesforce.com/en/modules/data_security
Sharing Architecture whitepaper:
Apex managed sharing wiki:
More on Apex Managed sharing from the Apex dev guide:
Hands-On Training for Troubleshooting Record Access from DF13: