Lest We Forget

Just a quick study note.

Now this could be my short post I have so desperately wanted to write for sometime!

It dawned on me today that we may be losing sight of the big picture here. I am picking that a great number of people are confused by all this DSL, GAT and Software Factory talk. What is the relationship here? How come we can't talk about factories without talking about DSL's and GAT? Which one is related to the other?

I've been trying to put this succinctly to those whom I discuss about this, so here goes the 20 second elevator pitch on what a factory is today with today's technologies, used for building today's solutions. (there are plenty of other scenarios, but this is the commonly conceived one). Remember this is a practical description (NOT definition!).

A factory is a collection of related DSL's (views) that describe the components of a product from different perspectives (view points). We use recipes (GAT) to automate the configuring of those DSL's or the artifacts that are created by them, or development of them as a whole. The generated product (using DSL's and GAT) is implemented in code that is generated to configure underlying frameworks and class libraries already targeted at this type of solution. The views are related by a logical product architecture, inferred or explicitly represented in artifacts (could be solution items such as source code or configuration files).

In all this work we've been doing, bringing people up to speed with how to build factories with and how they relate to what patterns & practices are releasing, it easy to lose sight of what we are actually doing here.

I have to say this. If you understand the difference between problem domain and solution domain in software design, you will know that factories are all about the solution domain. We are so far away from modeling problem domain and turning it into software just yet - forget it for now. It has proven impractical at this time, it is too big a step at this point, we need to evolve to that later.

If you wonder what your DSL's should model in the context of software factories, then always "model existing solution domain components". In other words, model a solution (or part of solution) that already exists or one you derived from what already exists from multiple instances of that solution that someone built before. A framework is the greatest starting point. Take your framework and model it. Build your DSL's to expose its variable parts (basically its API's and their parameters). Your DSL's will generate 'configuration code' that runs on that framework. You can try to relate these DSL's through various cross-references or naming. Either way, you will want to tie them into some overall product architecture somehow. How you do that is up to you. Innovate! We did this in the EFx Factory by creating a mapping layer from DSL to generated artifacts (source files). Basically a logical to physical architecture mapping. You can do it however it makes sense for your factory. Just make sure you base it upon existing solution domain concepts.

There, I did it, a short post.

Comments

• Anonymous
  September 23, 2007
  PingBack from http://msdnrss.thecoderblogs.com/2007/09/23/lest-we-forget/

• Anonymous
  September 24, 2007
  While you surely can start from the solution domain, I would not recommend it. The benefits from domain-specific languages are then unnecessarily limited. Instead, DSLs work much better if you inspect during their creation domain concepts, variation space, physical structures, look and feel rather than current code. This is a well known and practical approach. Most of the cases described at the OOPSLA workshop on Domain-Specific Modeling (http://www.dsmforum.org/DSMworkshops.html) demonstrate this as well as the public cases on DSM (http://www.dsmforum.org/cases.html).

• Anonymous
  September 24, 2007
  The comment has been removed