clarify the purpose of Session-Commands

[Ichthyostega]

As Lumiera Architect,
I want to evaluate the future role of Commands vs. Events,
in order to decide which part of the existing Command implementation to maintain.

Change of Goals

Initially, a Command implementation was established based on the Memento-Pattern. The idea, that Commands shall be logged prior to execution as in a Database was a stated goal from the very beginnings of the Lumiera project. However, taking this idea seriously and thinking through the consequences led us to discover various concerns and solutions — which at the same time were also encountered in the realm of industrial IT systems, notably in the finance industry (where I worked for 20 years). This resulted in a shift towards an Event Sourcing (and CQRS) architecture.

Meanwhile, the connection between Session core and UI (#1099, #1042) was actually established, in a different way than initially expected: Since this crucial link became a messaging system...

• the role of the »Session Objects« is now mostly conceptual, turned into an internal detail of the Steam-Layer, and subject to realignment to concerns of event propagation and eventual consistency.
• the UI no longer depends on a data model, rather on a structured entity scheme with semantic attributions
• and what is bound into and executed by the commands will be an instruction language rather,
  rendering the capture of memento state a moot point

Given that the implementation of the existing Session-Command framework was quite a stretch with the limited (pre C++11) language capabilities of that time, it seems that a re-defined Command implementation could be much more accessible — which however requires a clarification about

• the role of Command parameters
• the symbolic nature commands seem to take on in the emerging UI framework