The purpose of Selenium is to create UI-driven integration tests.
Integration tests verify that all components of your system work correctly when deployed together. Integration tests are not a sufficient test strategy and complement other test strategies having a different focus, for example unit-testing and acceptance testing.
UI-driven tests are inherently brittle, although Selenium and Watir are a step up from the early days of record-and-playback tools. There are several ways to deal with this problem - here's is a compilation of advice from some world-class experts:
Don't try to get all your test coverage from this type of tests. Robert C. Martin argues that your code coverage by integration tests should be about 20%. It is simply impractical to test all paths of execution when the input is several application layers away.
Get most of the test coverage from unit- and acceptance tests. Look for links to Gojko Adzic's articles in FinnNk's answer. Adzic argued repeatedly about testing business logic through acceptance tests and bypassing UI.
But some amount of UI-driven tests still needs to be written. This is where you need some practical advice in addition to "don't test your business logic via UI." I'd recommend Patrick Wilson-Welsh's blog as the starting point.