Systematic Reuse Success Factor #4 – Domain Context

There isn’t one right way to build reusable software assets. Your business goals, technical environment, iteration and release plans all contribute to both the timing and nature of design decisions. Refactoring existing code to meet business goals is also context driven. Consider:

  1. What product features typically go together?building blocks
  2. Do certain features vary more than others across products?
  3. Is it possible to vary a product feature at runtime or design-time?

All these questions guide design. For instance, if the goal is to support variability at runtime you could support adding new parameters and changing existing ones without code changes or application restarts. As you work on design, keep your domain relevant variations at the back of mind!

Take an example of a widget shop that needs to market its widgets. The user story is to produce different marketing labels based on widget type. There could be several variations to support – frequency of changes to label information, number of words, language, data formatting, mixture of static and dynamic messages that make up a label etc.

Depending on the complexity of your domain, the features could vary simultaneously or in isolation. Consider some of these variations and their impact on design.

#1 Label contents are only static content – you could use a single LabelGenerator using a file configuration.

#2 Label contents are a mixture of static and dynamic content – LabelGenerator now needs two sub-components – a StaticContentGenerator and a DynamicContentGenerator.

#3 Label contents are a mixture of static and dynamic content. Static content is multi-lingual. – In addition to the content generators you need an internationalization component that can support multiple languages

#4 Label contents are a mixture of static and dynamic content. Static content is multi-lingual. Date and currency formatting varies based on country – All components of #3 plus a DateFormatter and CurrencyFormatter based on locale.

Next time you start a project, understand more about the drivers for change in your problem domain. Your domain and the associated context should drive reuse. The more you understand the drivers the easier it is to decide what and how your software assets need to be reusable.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :

About these ads

5 Responses to Systematic Reuse Success Factor #4 – Domain Context

  1. […] This post was Twitted by t_agile […]

  2. […] specifically the aspects that vary and the number of variations you need to support. This is very critical to plan for the reusable […]

  3. […] bound polymorphically. This concept can be further extended based on the quantity and quality of variations. For instance, the message construction can be realized using a common interface with multiple […]

  4. […] code generated for developers? Take care to highlight ease of integration and the multiple variability mechanisms to your […]

  5. […] break down data into multiple chunks, and returning only those that the client is interested in). Understand your domain to identify service capabilities that could support client […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: