Buch auf englisch?

[Ole Bulbuk]

Hallo liebe Freunde des fluessigen,

ich schreibe diese Mail an alle, weil die Antwort vermutlich fuer viele interessant ist. Eigentlich richtet sich meine Frage an Ralf.

Ich habe noch recht gut die Begeisterung und Veraenderungen in Erinnerung, die durch Rod Johnsons Buch "Expert One-on-One J2EE Design and Development" ausgeloest wurden. Schliesslich ist dadurch ja auch die Firma SpringSource entstanden.

Meine (nicht ganz bescheidene) Hoffnung ist, dass das Buch von Ralf ueber Flow-Orientierung etwas aehnliches ausloesen koennte. Voraussetzung fuer einen derartigen Erfolg ist aber wohl, dass es (auch) eine englische Variante des Buches gibt.

Ist das geplant? Oder soll das Buch nur auf deutsch erscheinen?

 

Viele Gruesse

 

Ole

-- 

Martin-Luther-Platz 3
91054 Erlangen
Tel.: 09131 / 975 97 90
Handy: 0170 / 241 6339

[Ralf Westphal]

hallo, ole!

natürlich wäre ein FD buch auf englisch ne coole sache.

noch cooler wärs allerdings, überhaupt erstmal eines zu haben.

60 seiten oder so hatte ich geschrieben - bis ich an den punkt kam, dass ich dacht: nein, so ist es auch noch nicht richtig gesagt :-|

seitdem ist das projekt on hold. auch wegen privater angelegenheiten, die grad sehr viel aufmerksamkeit brauchen.

der punkt, an dem ich mich gerieben habe, wo ich noch nicht klar bin: zustand.

zustand in flows... da fühle ich mich noch nicht so wohl mit den bisherigen ansätzen. irgendwas fehlt noch.

nicht privater zustand von funktionseinheiten. der ist ok und einfach.

ich meine gemeinsamen zustand, shared state über funktionseinheiten hinweg.

den haben wir bisher als abhängigkeit modelliert. kann man machen. funktioniert durchaus.

dann habe ich ihn mal als funktionseinheit im fluss modelliert. kann man auch machen. funktioniert ebenfalls.

aber das ist alles "nur" pragmatische praxis. auch schön - doch es fehlt etwas, ein theoriegerüst dahinter.

flow design im allgemeinen finde ich von theoretischer seite her gut untermauert.

shared state im speziellen jedoch... nein, da hakt es noch. und ich vertraue meinem gefühl, dass das etwas bedeutet.

da will noch etwas herausgearbeitet werden. darüber muss ich noch nachdenken. oder wir hier in der gruppe denken mal drüber nach.

zur einstimmung kann jeder eine simple kata machen, z.b. die app kata questionnaire oder auch tic tac toe:

http://clean-code-advisors.com/ressourcen/application-katas

oder einen kleinen taschenrechner.

überall kommt shared state vor. und der sollte natürlich nicht im UI oder einer DB gehalten werden.

aber wie dann? gibt es ein muster? gibt es regeln, guidance?

ohne das thema noch besser herauszuarbeiten, lohnt ein FD buch nicht so recht.

über pragmatische lösungen wie bisher möchte ich dafür hinaus sein.

-ralf

--
Ralf Westphal - One Man Think Tank
Hans-Henny-Jahnn-Weg 44
D-22085 Hamburg
Germany
Tel 0170-3200458
Email in...@ralfw.de

[Ole Bulbuk]

Hallo Ralf,

natürlich wäre ein FD buch auf englisch ne coole sache.

noch cooler wärs allerdings, überhaupt erstmal eines zu haben.

Ja, klar. So ein feinnes Buch ist halt ein richtig grosser Hebel.

Damit kann man was bewegen. 

der punkt, an dem ich mich gerieben habe, wo ich noch nicht klar bin: zustand.

zustand in flows... da fühle ich mich noch nicht so wohl mit den bisherigen ansätzen. irgendwas fehlt noch.

nicht privater zustand von funktionseinheiten. der ist ok und einfach.

ich meine gemeinsamen zustand, shared state über funktionseinheiten hinweg.

Meinst Du wirklich gemeinsamen Zustand im Sinne einer gemeinsamen Konfiguration oder gemeinsamer globaler Daten?

Das hoert sich noch relativ einfach aber auch eher unnoetig an.

Oder meinst Du vielleicht Zustand, wie manche boese Menschen ihn in einer serverseitigen Session aufheben?

Meiner bescheidenen Ansicht nach sollten Sessiondaten soweit wie moeglich vermieden werden.

Vieles laesst sich leicht durch einen Cache ersetzen. Der zerstoert die Skalierbarkeit der Anwendung nicht und macht auch sonst weniger Probleme.

Das bisschen, was man dann wirklich noch an Session braucht, kann der Client aufheben und (notfalls) bei jeder Anfrage wieder mitschicken.

Das ermoeglicht immerhin RESTful APIs und macht das Ganze skalierbar, testbar, ...

den haben wir bisher als abhängigkeit modelliert. kann man machen. funktioniert durchaus.

dann habe ich ihn mal als funktionseinheit im fluss modelliert. kann man auch machen. funktioniert ebenfalls.

aber das ist alles "nur" pragmatische praxis. auch schön - doch es fehlt etwas, ein theoriegerüst dahinter.

flow design im allgemeinen finde ich von theoretischer seite her gut untermauert.

shared state im speziellen jedoch... nein, da hakt es noch. und ich vertraue meinem gefühl, dass das etwas bedeutet.

da will noch etwas herausgearbeitet werden. darüber muss ich noch nachdenken. oder wir hier in der gruppe denken mal drüber nach.

zur einstimmung kann jeder eine simple kata machen, z.b. die app kata questionnaire oder auch tic tac toe:

http://clean-code-advisors.com/ressourcen/application-katas

oder einen kleinen taschenrechner.

Zumindest bei tic tac toe sieht es doch arg nach Session aus.

Der aktuelle Spielstand muss halt germerkt werden.

Das skaliert aber natuerlich nur, wenn es nicht der Server, sondern die Clients machen.

Die muessen den Stand natuerlich verschluesselt bekommen damit sie nicht mogeln.

überall kommt shared state vor. und der sollte natürlich nicht im UI oder einer DB gehalten werden.

aber wie dann? gibt es ein muster? gibt es regeln, guidance?

Fuer mich persoenlich gilt da folgende Regel/Reihenfolge:

1. Gar nicht merken. Zustand ist boese.
2. Cache verwenden. Dann kann der Zustand notfalls auch noch anders reproduziert werden (DB, neu berechnen, ...).
3. Client den Zustand verwalten lassen. Gegebenenfalls signiert oder gar verschluesselt damit nicht geschummelt wird. Bei Webanwendungen kann der Client das per JavaScript machen oder auch einfach per Coockie (beschraenkt auf 4 KB).
4. Wenn nix anderes hilft, dann nehm ich eben die Datenbank. Das machen die PHP-Heinis schon immer so und das skaliert wenigstens auch, wenn es nicht besonders schoen oder schnell ist. Aber es ist immerhin ein klarer dokumentierter Weg und Wildwuchs ist selten.

ohne das thema noch besser herauszuarbeiten, lohnt ein FD buch nicht so recht.

über pragmatische lösungen wie bisher möchte ich dafür hinaus sein.

Ich weiss nicht, ob Dir meine privaten Ansichten da weiterhelfen.

Aber das funktioniert eigentlich ganz prima.

[Ralf Westphal]

Am 1. März 2012 16:41 schrieb Ole Bulbuk <o...@bulbuk.de>:

Meinst Du wirklich gemeinsamen Zustand im Sinne einer gemeinsamen Konfiguration oder gemeinsamer globaler Daten?

Das hoert sich noch relativ einfach aber auch eher unnoetig an.

Oder meinst Du vielleicht Zustand, wie manche boese Menschen ihn in einer serverseitigen Session aufheben?

Ich meine Daten, die innerhalb desselben Flusses oder in verschiedenen Flows benötigt werden.

Und ich meine nicht unbedingt Web-Anwendungen. Sessions also kein spezielles Thema.

Nimm den Taschenrechner als Beispiel. Bei jeder Ziffer wird eine Zahl akkumuliert. Bei jedem Operator wird eine Berechnung mit dem Ergebnis der letzten durchgeführt. 2 Datenwerte sind da Zustand über Interaktionen hinweg.

Und diesen Zustand soll man in einem Cache halten? Kaum. Und selbst wenn: wie wird der Cache in die Flows gebracht? Als Abhängigkeit? Das ist ja meine Frage: In welcher Weise kommen Funktionseinheiten in einem Fluss an shared state?

[Ole Bulbuk]

Meinst Du wirklich gemeinsamen Zustand im Sinne einer gemeinsamen Konfiguration oder gemeinsamer globaler Daten?

Das hoert sich noch relativ einfach aber auch eher unnoetig an.

Oder meinst Du vielleicht Zustand, wie manche boese Menschen ihn in einer serverseitigen Session aufheben?

Ich meine Daten, die innerhalb desselben Flusses oder in verschiedenen Flows benötigt werden.

Und ich meine nicht unbedingt Web-Anwendungen. Sessions also kein spezielles Thema.

Doch, doch. Die Unterscheidung ist immer wichtig. Globale Weisheiten/Daten wuerde ich immer versuchen direkt bei den betroffenen Operationen zu speichern.

Daten, die von den User-Eingaben abhaengig sind wuerde ich immer versuchen als normale Flow-Daten zu behandeln.

Nimm den Taschenrechner als Beispiel. Bei jeder Ziffer wird eine Zahl akkumuliert. Bei jedem Operator wird eine Berechnung mit dem Ergebnis der letzten durchgeführt. 2 Datenwerte sind da Zustand über Interaktionen hinweg.

Die koennen doch wunderbar von einer Operation zur anderen als Teil des Flows weitergereicht werden.

Da muss man doch keinen Umstand draus machen. Vielleicht habe ich das Problem auch noch nicht verstanden.

Aber das sind doch keine Datenmengen, die einem Sorgen machen.

Die koennen doch problemlos weitergereicht werden (notfalls von einem Client zu einem Server; verwaltet wuerden sie aber nur auf dem Client).

Und diesen Zustand soll man in einem Cache halten? Kaum. Und selbst wenn: wie wird der Cache in die Flows gebracht? Als Abhängigkeit? Das ist ja meine Frage: In welcher Weise kommen Funktionseinheiten in einem Fluss an shared state?

Cache fuer simple Zahlen ist natuerlich Quatsch.

Aber wenn eine Funtionseinheit/Operation einen Cache gebrauchen kann, dann sollte sie damit initalisiert werden. Dann kann sie darin groessere Datenmengen zwischenspeichern und spaeter wieder heraushohlen.

Grundsaetzlich fliessen die Daten (shared state oder was auch immer) wunderbar in einem Fluss von einer Funktionseinheit zur anderen. Da hat man es doch eigentlich sehr einfach. Selbstverstaendlich sind da mal mehr Daten dabei als eine einzelne Operation braucht. Na und?

Fuer mich sieht es momentan nach einer Suche nach einer Theorie fuer ein nicht existentes Problem aus. 

[Ralf Westphal]

Am 2. März 2012 11:19 schrieb Ole Bulbuk <o...@bulbuk.de>:

Grundsaetzlich fliessen die Daten (shared state oder was auch immer) wunderbar in einem Fluss von einer Funktionseinheit zur anderen. Da hat man es doch eigentlich sehr einfach. Selbstverstaendlich sind da mal mehr Daten dabei als eine einzelne Operation braucht. Na und?

das ist für mich ein entscheidenden "na und?". denn damit geht die wiederverwendbarkeit flöten.

so sieht ein flow aus:

-(x)-> F1(x, A) -(y)-> F2(y) -(z)-> F3(z, A)

an den FEs ist notiert, welche daten sie brauchen. an den verbindungen steht, was fließt.

F1 und F3 arbeiten auf denselben daten A. das ist shared state, denn A fließt nicht in den flow hinein. hinein kommt nur x.

F2 ist konzentriert auf y.

was du vorschlägst, sieht dann z.b. so aus:

-(x)-> F1(x, A) -(y,A)-> F2(y, A) -(z,A)-> F3(z, A)

plötzlich muss F2 auch noch etwas mit A tun und sei es nur, A durchzureichen. das ist misslich, wenn F2 in einem anderen kontext wiederverwendet werden soll:

-(s)-> F8(s) -(y)-> F2(y) -(z)-> F9(z)

zustand durchreichen ist technisch einfach. aber es verwässert den flow. jedenfalls solange das durchreichen explizit implementiert werden muss wie heute.

Fuer mich sieht es momentan nach einer Suche nach einer Theorie fuer ein nicht existentes Problem aus. 

Viele Gruesse

Ole

-- 
Martin-Luther-Platz 3
91054 Erlangen
Tel.: 09131 / 975 97 90
Handy: 0170 / 241 6339

[Olaf Krumnow]

----- Ursprüngliche Nachricht -----

Von: Ralf Westphal

Gesendet: 02.03.12 13:07 Uhr

An: event-based...@googlegroups.com

Betreff: Re: Buch auf englisch?

[Ole Bulbuk]

Grundsaetzlich fliessen die Daten (shared state oder was auch immer) wunderbar in einem Fluss von einer Funktionseinheit zur anderen. Da hat man es doch eigentlich sehr einfach. Selbstverstaendlich sind da mal mehr Daten dabei als eine einzelne Operation braucht. Na und?

das ist für mich ein entscheidenden "na und?". denn damit geht die wiederverwendbarkeit flöten.

so sieht ein flow aus:

-(x)-> F1(x, A) -(y)-> F2(y) -(z)-> F3(z, A)

an den FEs ist notiert, welche daten sie brauchen. an den verbindungen steht, was fließt.

F1 und F3 arbeiten auf denselben daten A. das ist shared state, denn A fließt nicht in den flow hinein. hinein kommt nur x.

F2 ist konzentriert auf y.

was du vorschlägst, sieht dann z.b. so aus:

-(x)-> F1(x, A) -(y,A)-> F2(y, A) -(z,A)-> F3(z, A)

plötzlich muss F2 auch noch etwas mit A tun und sei es nur, A durchzureichen. das ist misslich, wenn F2 in einem anderen kontext wiederverwendet werden soll:

-(s)-> F8(s) -(y)-> F2(y) -(z)-> F9(z)

zustand durchreichen ist technisch einfach. aber es verwässert den flow. jedenfalls solange das durchreichen explizit implementiert werden muss wie heute.

Jetzt verstehe ich endlich dein Problem.

Das habe ich in meiner Implementation (hoffentlich recht elegant) geloest:

1. Wiederverwendbare Funktionseinheiten (in der Praxis ca. 70%) arbeiten auf einem generischen Typ, den sie einfach durchreichen.
2. Um an ihre Daten zu kommen arbeiten die generischen Funktionseinheiten mit Gettern, Settern und Factories.
3. Die Getter, Setter und Factories bekommen sie im Konstruktor uebergeben. Der Konstruktor wird je nach Kontext entsprechend aufgerufen.
4. Getter, Setter und Factories sind recht triviale "Closures/Lambdas", die aus einer DSL heraus generiert werden koennen.

Ich wuerde gerne mal "meine" DSL und den generierten Code diskutieren.

Da muss ich aber erstmal meinen Chef fragen...

[Ralf Westphal]

Am 2. März 2012 13:20 schrieb Ole Bulbuk <o...@bulbuk.de>:

Jetzt verstehe ich endlich dein Problem.

gut, dass wir drüber geredet haben :-)

 

Das habe ich in meiner Implementation (hoffentlich recht elegant) geloest:

1. Wiederverwendbare Funktionseinheiten (in der Praxis ca. 70%) arbeiten auf einem generischen Typ, den sie einfach durchreichen.
2. Um an ihre Daten zu kommen arbeiten die generischen Funktionseinheiten mit Gettern, Settern und Factories.
3. Die Getter, Setter und Factories bekommen sie im Konstruktor uebergeben. Der Konstruktor wird je nach Kontext entsprechend aufgerufen.
4. Getter, Setter und Factories sind recht triviale "Closures/Lambdas", die aus einer DSL heraus generiert werden koennen.

naja, dann modellierst du shared state als abhängigkeit.

nix neues ;-) (nur anders gelöst als bei EBC.)

meine frage ist damit nicht beantwortet: ist das der beste weg, um shared state zu modellieren?

[Ole Bulbuk]

Ich bin mir nicht sicher, dass du wirklich verstanden hast, was ich meine.

Deshalb nochmal etwas expliziter:

Zentrale Datenstruktur:

struct A { X x, Y y, Z z, B b, ... }

Der Flow ist dann:

-(X)-> F1(A) -(A)-> F2(A) -(A)-> F3(A)

Operationen:

F1<T, U> bekommt: Generics T=X, U=A; Factory fuer A und Setter fuer A,X

F2<T> bekommt: Generics T=A; Getter fuer A,Y und Setter fuer A,Z

F3<T> bekommt: Generics T=A; Getter fuer A,Z

So ein Getter ist einfach:

public interface Getter<T, U> {

  public U get(T t);

}

Ein Setter entsprechend:

public interface Setter<T, U> {

  public void set(T t, U u);

}

Eine Factory schliesslich:

public interface Factory<T> {

  public T create();

}

 

Ich hoffe das macht es etwas klarer.

F1, F2 und F3 koennen also absolut generische und wiederverwendbare Funktionseinheiten sein.

Die wissen gar nicht auf welchen Daten sie eigentlich arbeiten und was sie da genau an die naechste Funktionseinheit senden.

Brauchen sie ja auch nicht. Der Compiler sorgt dafuer, dass es passt und die Funktionseiheiten koennen dank Getter, Setter und Factories arbeiten.

Die Getter, Setter und Factories sind schoen in der DSL dokumentiert und alles ist gut (meiner Ansicht nach).

[Denis]

Hallo Ole,
leider ist es nicht klarer geworden.
Was bedeutet "F1 bekommt"?

Auch vermisse ich bei Deinen Getter-, Setter- und Factory-Interfaces
den Typparameter.
Aber vielleicht habe ich es missverstanden.

Könntest Du vielleicht ein kleines Beispiel bringen?

Denis

On Mar 2, 2:15 pm, Ole Bulbuk <o...@bulbuk.de> wrote:

> On Fri, 2 Mar 2012 13:27:19 +0100, Ralf Westphal  wrote:
>
> Am 2. März

> 2012 13:20 schrieb Ole Bulbuk :
>
> Jetzt verstehe ich endlich dein
> Problem.
> gut, dass wir drüber geredet haben :-)
>
> Das habe ich in
> meiner Implementation (hoffentlich recht elegant) geloest:
>

>         *

> Wiederverwendbare Funktionseinheiten (in der Praxis ca. 70%) arbeiten
> auf einem generischen Typ, den sie einfach durchreichen.

>         * Um an ihre

> Daten zu kommen arbeiten die generischen Funktionseinheiten mit Gettern,
> Settern und Factories.

>         * Die Getter, Setter und Factories bekommen sie

> im Konstruktor uebergeben. Der Konstruktor wird je nach Kontext
> entsprechend aufgerufen.

>         * Getter, Setter und Factories sind recht

> triviale "Closures/Lambdas", die aus einer DSL heraus generiert werden
> koennen.
>
> naja, dann modellierst du shared state als abhängigkeit.
> nix
> neues ;-) (nur anders gelöst als bei EBC.)
> meine frage ist damit nicht
> beantwortet: ist das der beste weg, um shared state zu modellieren?
>
> Ich bin mir nicht sicher, dass du wirklich verstanden hast, was ich
> meine.
>
> Deshalb nochmal etwas expliziter:
>
> Zentrale Datenstruktur:
>
> struct A { X x, Y y, Z z, B b, ... }
>
> Der Flow ist dann:
>
> -(X)->
> F1(A) -(A)-> F2(A) -(A)-> F3(A)
>
> Operationen:
>

> F1 bekommt: Generics

> T=X, U=A; Factory fuer A und Setter fuer A,X
>

> F2 bekommt: Generics T=A;

> Getter fuer A,Y und Setter fuer A,Z
>

> F3 bekommt: Generics T=A; Getter

> fuer A,Z
>
> So ein Getter ist einfach:
>

> public interface Getter {

>
> public U get(T t);
>
> }
>
> Ein Setter entsprechend:
>
> public interface

> Setter {

>
>  public void set(T t, U u);
>
> }
>
> Eine Factory schliesslich:
>

> public interface Factory {

>
>  public T create();
>
> }
>
> Ich hoffe das
> macht es etwas klarer.
>
> F1, F2 und F3 koennen also absolut generische
> und wiederverwendbare Funktionseinheiten sein.
>
> Die wissen gar nicht
> auf welchen Daten sie eigentlich arbeiten und was sie da genau an die
> naechste Funktionseinheit senden.
>
> Brauchen sie ja auch nicht. Der
> Compiler sorgt dafuer, dass es passt und die Funktionseiheiten koennen
> dank Getter, Setter und Factories arbeiten.
>
> Die Getter, Setter und
> Factories sind schoen in der DSL dokumentiert und alles ist gut (meiner
> Ansicht nach).
>
> Viele Gruesse
>
> Ole
>
> --
> Martin-Luther-Platz 3
> 91054
> Erlangen
> Tel.: 09131 / 975 97 90
> Handy: 0170 / 241 6339
>

> Links:
> ------
> [1] mailto:o...@bulbuk.de

[Christian Götz]

Hallo Ole,

mir würde auch ein konkreteres Beispiel gefallen, da ich auch so meine Probleme habe, das nachzuvollziehen.

Das Beispiel kannst du am besten gleich bei https://gist.github.com/ einstellen. Da ist das Quellcode-feeling besser, wenn man das dann liest. :-)

mfg

Christian

[Denis]

... Es muss nicht immer gleich Code sein ;-)

Aber ich habe noch eine Frage an Ralf. Was stört Dich an der
Modellierung der shared states über explizite Abhaengigkeiten? Ist es
nur so ein Bauchgefuehl oder hast konkreteres "Unwohlsein"?
Ich fand gerade das konzeptionelle Eingeständnis im Flow-Design,
Abhängigkeiten auch explizit zu modellieren, da wo sie notwendige
sind, wie etwa bei shared state, als sehr ehrlich und das Konzept
abrundend.

Bei mir war es sogar so, dass gerade dieser Umstand mich endgültig von
FD überzeugt hat, weil Du eben nicht versucht hast alles in ein
Prinzip - das des Data Flows - reinzupressen, sondern dies eben sehr
natürlich integriert hast.
Eine sehr unnatuerliche Modellierung wäre gerade die, shared states
über den gesamten Flow mitzuschleppen. Pragmatisch zwar möglich , aber
eben doch nicht natürlich.

Denis



On Mar 3, 9:00 am, Christian Götz <christian.g2...@googlemail.com>
wrote:

> Hallo Ole,
>
> mir würde auch ein konkreteres Beispiel gefallen, da ich auch so meine
> Probleme habe, das nachzuvollziehen.
> Das Beispiel kannst du am besten gleich beihttps://gist.github.com/einstellen.
> Da ist das Quellcode-feeling besser, wenn man das dann liest. :-)
>
> mfg
>
> Christian
>
> Am Freitag, 2. März 2012 14:15:16 UTC+1 schrieb OleB:
>
>
>
>
>
>
>
>
>

> > On Fri, 2 Mar 2012 13:27:19 +0100, Ralf Westphal <ralf...@googlemail.com>

> > wrote:
>
> > Am 2. März 2012 13:20 schrieb Ole Bulbuk <o...@bulbuk.de>:
>
> >> Jetzt verstehe ich endlich dein Problem.
>
> > gut, dass wir drüber geredet haben :-)
>
> >> Das habe ich in meiner Implementation (hoffentlich recht elegant) geloest:
>

> >>    1. Wiederverwendbare Funktionseinheiten (in der Praxis ca. 70%)

> >>    arbeiten auf einem generischen Typ, den sie einfach durchreichen.

> >>    2. Um an ihre Daten zu kommen arbeiten die generischen

> >>    Funktionseinheiten mit Gettern, Settern und Factories.

> >>    3. Die Getter, Setter und Factories bekommen sie im Konstruktor

> >>    uebergeben. Der Konstruktor wird je nach Kontext entsprechend aufgerufen.

> >>    4. Getter, Setter und Factories sind recht triviale

[Ralf Westphal]

tja... ich fand shared state als abhängigkeit auch nicht schlecht - bis der zu umständlich wurde.

dann hab ich shared state in den fluss eingebaut. bis das auch irgendwie doof war.

und nun frage ich mich: sind das einfach nur zwei legitime varianten? oder gibt es eine dritte? gibt es womöglich einen universellen gedanken, der hinter shared state liegt, den wir noch nicht erkannt haben?

vielleicht ist auch noch etwas grundsätzlich falsch gedacht beim flow design in bezug auf zustand.

vielleicht sollte es in einem flow wirklich keinen shared state geben? vielleicht sollte shared state nur ganz am anfang und/oder ganz am ende stehen?

oder ist shared state nichts anderes als persistente daten? (nur eben nicht persistent ;-)

volatile daten könnte man als optimierung ansehen. wenn wir das tun und volatile shared state stattdessen persistent modellieren... dann sehen unsere modelle anders aus. dann würde shared state nicht als abhängigkeit modelliert, sondern im fluss drin wie auch persistente daten.

tja... einfach so gedanken aus einem gewissen unwohlsein heraus.