Domain specific patterns

One way to become a recognized expert in your line of work is to become versed in your organization's domain specific design patterns. You will gain an exponential level of recognition if you contribute to codifying these patterns. Be proactive in documenting and sharing design patterns specific to your problem (business) domain. Few organizations invest resources into codifying the non-standard design patterns even though they are implemented often (hence the name). If you're the one recognizing and documenting domain specific design patterns you'll become a recognized expert.

By now many organizations have internal wiki-like collaboration tools. That’s the best place for you to start documenting these domain specific design patterns. Use that collaboration space to involve others. To be effective select an existing (or create your own) framework for describing design patterns. Many frameworks and approaches exit, pick one that works and modify as you go along. Just remember that design patterns apply to different level of design granularity.

Why is this important? Reuse at architectural level. Further, domain patterns may lead to reference architectures. This will help you and your organization reuse design concepts. Reference architecture (specific to your domain) may then result in an implementation framework (again, specific to your domain) that may contribute to development of product lines.


Constantin Kostenko
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Comments

Anonymous said…
Recognition and knowledge management aside ... keeping track of design patterns in a personal notebook (file, etc.) helps me keep track of tools of the trade. The culture of your company will determine if sharing something like this with everyone will yield benefit.

Popular posts from this blog

Why we do agile

Quality Attribute Refinement