[lmm]

Create types that express the requirements that you have, and use them to ensure that requirements are always met. For example, if some fields should only be accessed by administrators, have an AdministratorsOnly type; if some method can only be invoked in a transaction, have a MustHappenInTransaction type. I find that when you have cross-cutting requirements, types are often the most lightweight way to express them.

[InfiniteRand]

Planning out a type system to match business requirements sounds like architecture level work to me (especially if you use a diagram to plan out those type relationships/hierarchy).

Of course my perspective might be skewed, I have only really worked in small teams.

[lmm]

You don't plan it. You let it evolve to meet your business requirements. As the requirements change, so do the types you use.