If you mean representing individual business rule checks with exceptions, then I don't think it's a very good idea. Many times you have to report more than one failed condition, and not stop on the first one.
On the other hand, I do believe that checking for all rules and then throwing an exception with the summary is a good practice.
As Robert noted in a comment, I really don't think you can fully encompass all your design constraints in one place. Since you mention that you're intending to document your design constraints to assist with your design decisions, I'm assuming you are working in a waterfall-style development environment. See the Criticism section on Wikipedia regarding waterfall development - while waterfall development may be justified in some cases, there's a reason why agile development is catching on. Since you are free to start developing a product in small increments, as soon as you find that something doesn't work, you throw out that piece and then try a different approach. It's also much more reactive to changing requirements over the course of a project.
Waterfall development often wastes lots of administrative time up front - how many of us have had to deal with a requirements document that is many dozens of pages long, only for it to be essentially useless towards the end of the project, since the requirements have changed over the course of its development?
So far, I haven't directly answer your question regarding how to document a design constraint; rather, I'm suggesting that you don't do it all up front. You don't describe what your development environment is like (meaning, if it's in a large company, you're self-employeed, etc.), but if you can change the expectations of what needs to be delivered up front before any development is done, I think that will help you enormously. If I can twist your question into, "What should I document up front?", then I would suggest you look into formulating user stories instead, which should better document the true needs that should be known up front.
(By the way, if you are working on a solo or small team, you would also benefit from reading up on lean development, which emerged from the Agile movement, and further focuses on removing waste from the development process).
Edit, based on Nicholas' comment:
It sounds like you are probably in a tough spot. The above links in my answer cover each of those areas that you're not familiar with (jump to the top of the Criticism link to see the full scoop on Waterfall development - if you're not familiar with Waterfall versus Agile development, it's almost certain you are doing the former).
Do you have a feeling for how flexible your management's expectations are for what a development project entails? If you feel comfortable bringing the idea up to them, I think you would really benefit from a lean technique, though admittedly, without having a person experienced in lean development there to guide you along, you might find it daunting at first.
If, by chance, you have a Pluralsight subscription (or don't mind signing up for the free trial), their course called "Best Practices for Software Startups" covers the principles behind lean development and would give you arguments to bring to your management as to why you shouldn't try to plan all these design constraints right from the start of a project. (Alternatively, there are a number of presentations you can watch on YouTube).
Best Answer
These guidelines/idioms are called Constrained Programming, which is not easy thing to do. It is used for modeling and solving combinatorial problems (NP-hard, NP-complete). I can recommend you one book - Principles of Constraint Programming. This book is one of the best books on the subject, but, still, after reading it you still won't be able to apply it in practice.
But, you will be able to do that by getting familiar yourself with Gecode - a toolkit for developing constraint-based systems and applications. Gecode provides a constraint solver with state-of-the-art performance while being modular and extensible.
I can say that this subject is very interesting, I'd say one of the best courses I had during my studies. Btw, the author of Gecode, was my professor, so I was very lucky :)