Solution Domain Artifacts

You’re in Munich, and want to travel to Frankfurt. Given the time and place constraints, let’s say your best choice is to take a train. That is the problem. The Deutsche Bahn is your solution provider. And the solution provider decides that you need to learn a concept inorder to avail of the solution — the concept of a train ticket. The train ticket is a solution domain artifact. It is a concept that is not present in the problem domain (travelling by train from one place to another). Inorder to use the solution though, you need to learn about the solution domain artifact (the ticket). This post is about solution domain artifacts in software design.

[Disclaimer: this is what I call a solution domain artifact. You may call it by another name. Romeo and Juliet — II. 2.]

Let’s take an example relevant to us. Let’s say you want to embed a Javascript interpreter in your application. Since we are, of course, from the old school, the application is necessarily written in C (and command line based — more about this application in a later post), and our javascript engine of choice is spidermonkey. While building it, you realize that you need to know, apart from the Javascript language itself, at least the following concepts so that you can get the interpreter to do any work:

  • a runtime, represented by a JSRuntime object
  • a context, represented by a JSContext object
  • an error reporter, which is a callback function to handle errors

The remaining artifacts are not introduced by the solution domain itself — things like standard classes, objects, properties and functions are artifacts in the problem domain. Their manipulation was what you set out to do originally.

As another example, consider some SDAs that your grandma has to learn just to send an email to her son:

  • web browser
  • menu
  • scroll bar
  • button
  • URL
  • login credentials
  • e-mail address

Pause.

Does the tired architect want to tell you what he thinks about solution domain artifacts? No. He wants you to think about them.

Resume.

He’ll give you more fodder for thought, though.

As a designer of a component, you should minimize the artifacts that you expose your (potential) clients to. An artifact represents a cost, an investment that has to be made by your potential client. To the designer, it represents the cost of documentation and tech support.

Designers and architects often get carried away by building castles in the solution domain — mostly in the name of generalization and flexibility. A newcomer trying to develop a component would first have to know about the 33 types of components, the 12 categories they fall into, the 9 different interfaces that they can implement, the 10 different ways in which they can communicate, and of course the 7 XML files that have to be “suitably edited” to deploy the component.

Is it just a matter of the learning curve? No. Human minds and bodies haven’t evolved much in the past 1000 or so years. In other words, the human mind is designed for the requirements of a world many centuries past. There is a limit to the complexity that an average human mind can handle. It’s an engineering limit. When you create more abstractions, and the more complex your abstractions are, you deviate further from the average client. Your clients now have to be super-humans, or trained, disciplined, super-professionals, who can juggle all this complexity within their brilliant heads. And none of whom probably are available in the development team that is maintaining the product.

Components with fewer and simpler artifacts tend to be better maintained, widely used and more profitable. An ideal solution domain artifact is that which cannot be simplified further. An ideal solution presents only the minimally necessary and sufficient artifacts to the user.

The tired architect thinks that spidermonkey is fun to use, and that grandmas will forever be baffled by computers.

7 Comments

  1. jewwishes said,

    Oct 3, 2007 at 9:18 pm

    Interesting and informative.

  2. dcmetrocentric said,

    Oct 4, 2007 at 6:28 am

    Interesting… Are you involved in any large scale architecture system implementation?

    I’ll admit I had trouble following some of the things, but this post will be a good resource.

    http://www.dcmetrocentric.com

    James

  3. orangedandylion said,

    Oct 5, 2007 at 8:19 am

    sure it´s a matter of learning curve ;)

  4. Oct 13, 2007 at 7:27 am

    You just spoken out the predicament of the ordinery people, they want an instrument just as a pen in hand with few more buttons to deal to communicate or do other things electronically, that’s. Any further complication are jsut putting him off and tiring him.

  5. wwwebaycom said,

    Oct 13, 2007 at 7:44 am

    Yet some minds are better than other?

  6. lowerpericles said,

    Oct 13, 2007 at 2:36 pm

    “learning curve”

    The subconcious mind pathways (~upbringing) that leads to greater understanding and development of skills. Is a carpenter less intelligent than a mathematician’? The level of societies pre-determined by the aggressor.

  7. Dmitri said,

    Oct 13, 2007 at 5:04 pm

    All you’re really stating is that APIs can be too complex. Which we kind of know alrady.


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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s

%d bloggers like this: