Tag 2 Emails reflektieren - ralfw/emailwiedervorlage GitHub Wiki

Zweck und Umfang des Dienstes sind abgesteckt. Darüber könnte ich jetzt lange nachdenken und weiter Anforderungen sammeln und verfeinern... Aber nichts macht ja klarer, was gefordert ist, als etwas zu liefern und Feedback dafür zu bekommen. Deshalb möchte ich jetzt schon mit der Implementation beginnen. Außerdem dient die auch dem Bekanntwerden mit der nötigen Infrastruktur.

Ich muss etwas forschen, wie ich Emails aus einem Postfach herausholen kann. Zeitgemäß ist das wohl mit IMAP. Aber solche Forschung dient dem Kunden nicht. Der will etwas, das er versteht. Ein Inkrement sollte ihn bzw. einen Anwender daher involvieren. Wie könnte also ein Inkrement aussehen, in dem auch der Forschungsgegenstand vorkommt?

Dazu habe ich mal einen ersten Entwurf der Dienstarchitektur gemacht.

Die Hauptfunktionalität des Service besteht aus zwei wesentlichen Teilen: Der Einplanung von Wiedervorlagen und der Wiedervorlage. Beide greifen auf einen Mail Server zu. Untereinander kommunizieren sie über einen Speicher mit eingeplanten Wiedervorlagen.

Im heutigen Inkrement lasse ich allerdings den Speicher außen vor. Ich konzentriere mich auf einen Durchstich, der dem Kunden zeigt, dass er eine Email an den Dienst schicken kann und der sie ihm wieder vorlegt. Das passiert sofort. Der Dienst spiegelt sozusagen die Email zurück.

Um deutlich zu machen, dass der Dienst etwas damit tut, wird die Spiegelung etwas anders aussehen als das Original. Ich denke, sie wird eine kleine Einleitung enthalten, auf der der Originaltext folgt.

Außerdem werde ich den Dienst natürlich noch nicht in der Cloud betreiben. Ein lokaler Start reicht völlig aus.

Das Inkrement, nein, jedes Inkrement steht unter dem Motto: Keep it simple. Also wird auch der Quellcode nicht über Gebühr strukturiert sein. Aspekte bekommen eigene Klassen. Aber Komponenten setze ich einstweilen nicht auf. Alles steckt also in nur einer Assembly. Das reicht im Augenblick aus und verbaut mir nichts. Die Klassen kann ich jederzeit auf andere Assemblies verteilen.

Reflexion

Die Aspekte habe ich nur im absolut nötigen Maße implementiert. Im Flow werden deshalb Imap- und Smtp-Adapter direkt benutzt. Und auch einen Konfigurationsadapter gibt es.

Allerdings zeigt sich, dass beim Laden der Wiedervorlagen doch ein bisschen Arbeit nötig ist. Da könnte Funktionalität vom Adapter in die Domäne wandern.

Aufgehalten hat mich Unkenntnis des Verhaltens des Imap-Servers. Zwar hatte ich mit dem API gespielt (Forschung), doch dabei hatte ich nicht wirklich Wiedervorlage-Testfälle durchgespielt. So bin ich erst während der Produktion darüber gestolpert, dass Emails, in denen mehrere Wiedervorlage-Adressen stehen, mehrfach im Postfach auftauchen. Und dass nur in der ersten Kopie auch die BCC-Adressen stehen. So bin ich während der Produktion in die Forschung zurückgefallen.

Dennoch ist der Code am Ende sauber nach ISOP gegliedert im Imap-Adapter.