What Makes an Application?

People have talked for a while now about using an interface driven approach to application specification. From FLiP to 37 Signals, From our Intent Driven Design to Clark Valbergs Interface Driven Architecture, the interface drives the application.

So, as a thought experiment, if the interface fully defines the application, why would we need to do anything more than describe the interfaces using a set of sufficiently descriptive DSLs and then press the button to allow the application to write itself?

It seems to me pretty obvious that we can infer the data model from the object model for the majority of use cases. The fact is that there are only so many patterns for implementing relationships and inheritance within a relational database structure. Typically we as developers will use our experience to come up with the best way to implement a given object model manually, but there is really no reason why we couldn't encode our experience into a set of automatable heuristics that would make the key design decisions for us such as between one table per concrete class and one table per abstract class for implementing inheritance trees for green field applications. In most cases either the choice doesn't matter or if it matters it is fairly straightforward to encode the heuristics required to implement the right solution based on a set of requirements. I know this still isn't widely done, but it seems to me a fairly manageable task.

What is interesting though is that even the object model isn't a primary artifact. Why? Well, an object model is information about an object, its properties and its relationships. But the only objects, properties or relationships that matter are those exposed through an interface (when we include web service APIs, emails, log files, exports and any other outputs as forms of interfaces as well as screens). Given that, all you need to do is combine the distinct collection of objects and their properties and relationships used by your various screens and the object model can be synthesized automatically.

I'm still playing with all of this which is one of the reasons I'm implementing a lot of dynamic "call(MethodName, PropertyCollection)" style methods - so I can prototype lots of different approaches without having to keep rewriting interfaces, argument methods and the like. I'm basically writing a set of in-language DSLs and playing with them until they generate sufficiently rich applications for my set of use cases.

Of course, just because something is possible, that doesn't mean it is optimal. I can't imagine having to fully specify every property on every screen that uses it. But I could imagine an interface where you just add screens to an app, selecting an object (or creating a new one) and then selecting from a screen type (list, form, detail, report, etc.) and then either selecting or adding properties that relate to the variables that drive the DSL that relates to that screen type (lists have order by, filters, property lists, etc.) and selecting or adding related objects for everything from value lists in admin forms to product lists on a category detail page.

Of course, there are a bunch of issues from authentication to rollback and versioning that you wouldn't want to build in this way - they would be core object services with sufficient configuration flexibility to meet a reasonable subset of use cases and extension points for the edge cases.

So, anyone else playing with using a set of interface DSLs as the authoritative, DRY reference point for completely generating their apps?