views:

27

answers:

1

Previously whenever I've designed an application I've always treated categories as a major "top-level" piece of the design. But after becoming more interested in domain driven design and as database as "not" the model I'm not seeing categories in the same light anymore.

To me categories exist as a UI batch processing helper for navigating and management; "view category x", "do y with all things in category y" and aren't really part of an application's core unless specifically needed.

I'm struggling to see when categories exist as part of the core of an application and don't hang off the side as more of a helper. Anybody have any insight on how they treat categories or what situations necessitate categories being part of the domain of an application?

+1  A: 

I have always thought of categories as the result of a forced decision. For me the question is not whether categories should exist at the core, but what should their proximity of inheritance be from the core of a decision, which could establish a hierarchy of categories interspersed with logic/logical inheritance. The point of a domain then is to serve as a unified container of a field of knowledge as defined by the collective of its contents. My perspective is based on RDF which is a hierarchy of triplets where that hierarchy could represent a single category of knowledge represented through a context.