Normalising shared entities and applying constraints I'm looking for a specific "best practice" or "pattern" concerning entities that are shared between different entities, having a relation to one of many.

For example, one may have the generic entity "Address", which could be used to store the common address fields for customers, suppliers, employees, etc...

Would a seasoned DBA take that route or would he rather add the fields to the corresponding entities? I'm also thinking about maintainability, constraints that may (in the future) differ depending on the entity, things like that.

I would love to get references to any authoritative or established works on the subject.
The motivation for piling every kind of address into a single table is usually a misinterpretation and misapplication of the notion of code reuse.  

People can make the mistake of assuming that because you have two entities with some common set of attributes, that those attributes belong in their own table.  Sometimes entities have similar or identical columns coincidentally.  One wouldn't create a table for every NAME or DESCRIPTION or EFFECTIVE_DATE in your database, at least I hope one wouldn't be tempted to do this.

Some people mistakenly refer to all instances of removing columns out to their own table as normalisation.  Normalisation involves removing columns to their own tables, but not every instance of removing columns in this way is actually normalisation.  Normalisation prescribes very specific reasons for removing columns from a table.  If none of these reasons are applicable then you aren't normalising you're just making things complicated.

You have two correct ways of thinking about this:  Either your addresses all belong in one pile because you have an entity super-type that incorporates all of the common features of several entity subtypes, including addresses, - or - your addresses belong in separate piles (tables) according to each kind of thing that has an address and you write your procedural code against an IAddress interface which is implemented for each address table.

If you actually have an entity super-type, say LEGAL_ENTITY which has subtypes like CUSTOMER, VENDOR, EMPLOYEE and so forth, then having an ADDRESS table that is a child of LEGAL_ENTITY is a legitimate approach.  It may even be a valuable approach if there is significant overlap between your customers, vendors, employees (or whatever you're tracking) because you can change addresses once instead of in multiple locations when a legal entity moves.  On the other hand, if you don't have such a super-type, then you are going to face the problems pointed out by Richard Tallent.

If you keep your addresses in different tables according to what type of entity owns the address, then you can still achieve code reuse, assuming the language you are using supports interfaces.

As an aside: tvCa pointed out in a comment that addresses may be stored as columns rather than as rows in a separate table.  That will depend largely on how many addresses you need for each entity.  If you are tracking two addresses (physical, mailing) or if you are storing address history then go with an address table.  If you only store one address per addressee, then a separate table is likely overkill.