Domain Specific Categories

As a software engineer, how do you cope with information overload?  I suggest domain specific categories.  If the basic idea of domain specific languages (DSL) is a software language targeted at a specific area of problems, then domain specific categories (DSC) are an idea to create categories specific to an area of problems.

Here's some practical usage for the categories:

  • Organize sets of recommendations
  • Organize sets of principles, practices, patterns and anti-patterns
  • Organize sets of questions for more effective design inspections, code inspections, and deployment inspections
  • Improve communication and information sharing across teams and orgs by using the categories
  • Prioritize categories for effectiveness
  • Chunk up or partition work effectively

Here's practical examples illustrating domain specific categories:

In the examples above, notice how the headings are carefully chosen categories.  Each category that organizes recommendations is evaluated against both the problem space, such as security or performance, the application type, such as Web application, and then the specific technology at hand. 

Also notice how the baseline categories in the Web Application Security Frame become more specific and relevant in two ways:

  1. Information within each category is more specific (e.g. general Web Application input validation vs. input validation in ASP.NET)

  2. Categories are added or modifed based on the domain (e.g. ASP.NET has specific categories beyond than Web Application baseline set) 

Are there down-sides to not using a one set of categories fits all approach?  You bet ... but based on the results I've seen from practitioners, I'd bank on using more thoughtful and empirical categories that are tested against how actionable and relevant they are.

Comments (0)

Skip to main content