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 (3)

  1. Juha-Pekka says:

    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).

  2. Jezz Santos says:

    Thanks JiiPee,

    Damn. I knew it, that if I did a short post without all the context and preamble upfront, some smart cookie would call me on it! you win.

    Whilst I agree with you should not model your DSL on the actual code (classes, methods etc) of an existing solution, since that would be a poor low level abstraction.

    I am a firm believer that frameworks offer a supreme basis to model your DSL from, because the DSL further abstracts the framework and hides further details of it not relevant to your instance of a domain model. This is becuase frameworks are themselves the abstraction you speak of here. Put another way, if you are generating code from your DSL, then in this case the DSL generates framework configuration code only (that operates on the framework).

    You can do further abstraction here of course with your DSL to bring out the architecture of the product, but in most cases this will also be inferred implicitly or explicity by the framework too.

    Not to mention that deriving models from frameworks is the next logical step in software design and automation, which is not a huge leap for most in understanding and therefore likely to be more successful.

    Don’t you think?