A good architecture allows decisions to be deferred!

-- Uncle Bob Martin

The original intention starting Elastic Objects was to generate code from some design specifications in Excel. When analyzing an existing project I usually start to extract structures to get an overview about the code.

In some projects I used simple templates to generate functionality.

When working on a rather huge project with several hundred tables and thousands of fields I generated models, database, xml, tests and documentation. Starting point were the meta data from Oracle. I was fascinated about the possibility to automate core parts of an application independent of a target technology.

There are several partly solutions to generate code, e.g. from some xml schemas or mappings. But XML itself is hardly readable. Information is hidden in tags and attributes, a reader has to know the meaning.

Today we have the annotations hype with a more direct approach to the code. But here functionality is even more distributed than in old fashioned configuration files. And the "meaning" needs a good portion of framework knowhow. Even worse the solution is tied to the framework in almost every part. No pojos any more.

With a "model driven architecture" solution one could be independent of a specific programming language or framework. One can handle complex solution generating a core application instead of scrubbing code.

The template mechanism you find here has some specialities. Superficially it's just some text with

• placeholders ($[some path]) and
• calls (<call execute="TemplateCall.execute(templateKey)">)

Internally it's translated to a list of calls. These calls are not restricted to some template stuff but are directives e.g. loading new data.

If a target file is created, it could keep the tags from the templates. So the target acts as a template itself with generated parts and parts that can be modified. It's not just a dumb generation process.

Template solutions usually are more or less passive. Initially an object structure is created in an programming environment and this object is mapped in a more or less sophisticated way. With the concept of calls a template could actively DO something.

It could read some tabular data or write to a DB. A template is just a list of calls. The possible applications are far beyond some object to text mapping.

To access and modify object values via path a special wrapper class [EO] (ElasticObjects). With a list of calls together with serialization and deserialization it could use it to implement application services.

In todays we mostly have to deal with SOAP and REST with Web-Frameworks offering automatic mapping to objects. With REST even core functionality could be reduced to some annotations in the code.

With this kind of integrated mapping functionality is tied to application server and framework. One can not test functionality without it. The mapping allows only simple object mapping out of the box.

The core of Elastic Objects is rather small with no relevant dependencies and offers a lot of flexibility navigate through objects via path. So one can use it just for some simple object compare, merge or transform.

With these configuration objects it's possible to transparently trigger complex operations only with one key and optional control parameter in templates and service, sharing the same calling mechanism.

On the other side when working on a project with no, really bad or outdated specification, I always use Excel gathering informations to get an better overview in a human readable format.

The code is generated with a template mechanism. A template should

• load necessary data via calls
• access data via path

The result should act as a template itself to allow code modification outside the generated code.

A template is just a some text with a simple markup to "DO" something with focus on the resulting text.

With the JSON serialization one can easily implement web services.

• http://alteseite.schiffshistorisches-archiv.de/uploads/media/Deckschrubben.pdf
• https://www.heise.de/developer/artikel/Low-Code-Low-Quality-4134288.html
• https://de.wikipedia.org/wiki/Modellgetriebene_Softwareentwicklung
• https://levelup.gitconnected.com/how-to-use-technical-debt-in-your-favor-98bae475ba68 fluentcodes - elastic objects - mvn repository