Component-Entity-System approach to functional design
"Components are little single purpose bits of state" (aspects of state).
(Unlike monolithic objects) entities are "simple groupings of components". “They are nothing more than a unique ID".
"Systems are single purpose functions that take in a set of entities which have a specific component (or set of components) and update them".
I like this approach, because representing diversity with distinct types for every special case implies combinatorial increase of the number of types, and it's easy to get types' relations wrong.
Composable features or aspects as basic building blocks give more power to describe diversity. It also helps to make interactions/interference between features explicit (and probably reusable).
P.S. I probably need to write an essay on how many types is enough. Somehow, I never see this question discussed when people talk about types in the programming languages.