Datum | 10/2020 – … | |
Projekt | Plattform zur Verwaltung von bereitgestellten Dokumenten zu Verwaltungsdienstleistungen des Bundes | |
Branche | Innenministerium | |
Tätigkeit | Architektur, Implementierung | |
Beschreibung | Das Verwaltungsportal des Bundes soll für Bürgerinnen und Bürger sowie Unternehmen einen zentralen und komfortablen Zugang zu allen Verwaltungsleistungen des Bundes ermöglichen. Über die Anbindung an den Portalverbund werden ebenfalls die Leistungen der Länder und Kommunen zugänglich sein. Dabei verfolgt das Projekt eine ganzheitliche Lösung für Bürger/innen, Unternehmen und für Behörden. Die Umsetzung der einzelnen Applikationen erfolgte in einer hexagonalen Service-Architektur. In diesem Umfeld ist es notwendig hochgeladene und generierte Dokumente sicher zu verwalten. Für diesen Zweck wurde ein Dokumentenservice entwickelt. Dieser nimmt Dokumente entgegen, ohne diese unmittelbar zum Download anzubieten. Erst wenn diese durch die Verwaltungssoftware als final markiert werden, können Sie mit einem Zugriffsschlüssel für eine begrenzte Zeit vom Nutzer heruntergeladen werden. Temporär hochgeladene Dokumente werden zyklisch aus dem System gelöscht. |
|
Ausführung | Linux (Ubuntu) Java 14, Spring, Spring Boot Kubernetes, Docker REST, Jackson Hibernate 5, Oracle DB, H2, domain-driven design, hexagonal architecture Cloud MinIO, MapStruct, Micrometer, Lombok, Feign, Resilience4J, Testcontainers, OpenTracing, AOP, Mockito Junit 5, AssertJ, JSONAssert IDE: IntelliJ 2020 Vorgehensmodell: Scrum Tools: Maven, GitLab VCS: git |
Leistungsbeantragung
Datum | 02/2020 – 10/2020 | |
Projekt | Plattform zur Beantragung von Verwaltungsdienstleistungen des Bundes | |
Branche | Innenministerium | |
Tätigkeit | Architektur, Implementierung | |
Beschreibung | Das Verwaltungsportal des Bundes soll für Bürgerinnen und Bürger sowie Unternehmen einen zentralen und komfortablen Zugang zu allen Verwaltungsleistungen des Bundes ermöglichen. Über die Anbindung an den Portalverbund werden ebenfalls die Leistungen der Länder und Kommunen zugänglich sein. Dabei verfolgt das Projekt eine ganzheitliche Lösung für Bürger/innen, Unternehmen und für Behörden. Die Umsetzung der einzelnen Applikationen erfolgte in einer hexagonalen Service-Architektur. Die Leistungsbeantragung dient der Bereitstellung von Formularen für den Bürger, um eine Leistung zu beantragen. Für die Behörde wird eine Verwaltung dieser Anträge bereitgestellt, um die Vorgänge zu bearbeiten. |
|
Ausführung | Linux (Ubuntu) Java 14, Spring, Spring Boot Kubernetes, Docker REST, Jackson Hibernate 5, Oracle DB, H2, domain-driven design, hexagonal architecture Cloud MinIO, MapStruct, Micrometer, Lombok, Feign, Resilience4J, Testcontainers, OpenTracing, AOP, Mockito Junit 5, AssertJ, JSONAssert IDE: IntelliJ 2020 Vorgehensmodell: Scrum Tools: Maven, GitLab VCS: git |
Optimierung des Persistenzlayers durch multi-tenancy
Datum | 06/2019 – 12/2019 | |
Projekt | Plattform zum Versand von Nachrichten | |
Branche | Handel | |
Tätigkeit | Architektur, Implementierung | |
Beschreibung | Eine existierende Plattform zum Versand von Nachrichten wird durch eine Nachrichtenagnostische Komponente aus einigen Microservices (Abonnement Dienste) mit Anwendungsfall spezifischen Ereignissen zur Generierung von Nachrichten versorgt. Der Abonnementspeicherdienst ist für die Persistenz von unbekannten Events (im Json-Format) zuständig. Die Events werden durch die Definition eines Anwendungsfalls (Thema) im Themenverwaltungsdienst definiert und von Kafka gelesen und samt ihrer eindeutigen Themenkennung in einer PostgreSQL gespeichert. Der Abonnementverarbeitungsdienst verarbeitet zeitgesteuert die verschiedenen Themen durch Anfragen an den Abonnementspeicherdienst. Dabei reichert er die Daten mittels Anfragen an weitere Dienste an und leitet sie an die zentrale Nachrichtenplattform zum Versand weiter. Durch die Zunahme der Anwendungsfälle ist ein erheblicher Zuwachs des Datenvolumens (etwa 250 Mio. Zeilen) zu verzeichnen wodurch die Ausführung der DB-Abfragen zunehmend langsamer wird. Nachdem alle Zugriffsoptimierungen ausgeschöpft waren, entschlossen wir uns die Daten aufzuteilen und eine multi tenancy Architektur in der Persistenzschicht einzuführen. Als tenant dient hierbei ein Thema. Da die Anzahl der Themen zunehmend wächst ist die dedizierte Zuordnung einer DB-Instanz je Thema nicht möglich. Daher wird je Thema ein eigenes DB-Schema benutzt um die Indizes für die Abfragen klein zu halten. Die Hauptanforderung an die multi tenancy Komponente ist eine möglichst einfache Integration in den bestehenden Abonnementspeicherdienst. Dabei griff ich auf die Unterstützung von Hibernate zurück die mittels AspectJ an Annotations zur Selektion des Tenants gebunden habe. Dabei integriert sich alles weitgehend automatisch in Spring Boot. Nach der Datenmigration zeigten erste Vergleiche der Ausführungsgeschwindigkeiten der Abfragen hierbei eine Steigerung von mindestens Faktor 10. |
|
Ausführung | Linux (Ubuntu) Java 8/11, Spring, Spring Boot Amazon AWS, EC2 Docker REST, Jackson Hibernate 5, PostgreSQL, H2, redis, RabbitMQ (AMQP), Kafka (Nakadi) event driven architecture, domain-driven design, hexagonal architecture Cloud Mockito Junit 4/5, Hamcrest, AssertJ IDE: IntelliJ 2018 Vorgehensmodell: Scrum Tools: Maven, GitHub Enterprise VCS: git |
Werbekampagnen Verwaltung
Datum | 03/2019 – 05/2019 | |
Projekt | Service zur Verwaltung von Werbekampagnen | |
Branche | Handel | |
Tätigkeit | Architektur, Implementierung | |
Beschreibung | Architektur und Implementierung eines Microservices zur Verwaltung von Werbekampagnen. Der Microservice ist für die Stammdaten der Kampagnen zuständig und steuert die Generierung des relevanten Kundensegments durch einen weitere Microservice. Dabei verfügt er über eine Zustandsmaschine, die die Status der einzelnen Kampagnen steuert. Die Status werden auch vom Segmentierungsservice mittels Nachrichten aktualisiert. Der Segmentierungsservice sendet hierzu bei Beginn der Aussendung der Messages relevanter Kunden an die verarbeitende Plattform und bei Beendigung der Aussendung jeweils einen Statusupdate an die Kampagnenverwaltung zur Aktualisierung des Status. Die Microservices basieren auf Spring Boot. Die Kommunikation erfolgt über REST, AMQP sowie Kafka (gekapselt durch Nakadi). |
|
Ausführung | Linux (Ubuntu) Java 8/11, Spring, Spring Boot Amazon AWS, EC2 Docker REST, Jackson Hibernate 5, PostgreSQL, H2, redis, RabbitMQ (AMQP), Kafka (Nakadi) event driven architecture, domain-driven design, hexagonal architecture Cloud Mockito Junit, Hamcrest, AssertJ IDE: IntelliJ 2019 Vorgehensmodell: Scrum Tools: Maven, GitHub Enterprise VCS: git |
Mitarbeiter-Auskunftsdienst
Datum | 01/2019 – 02/2019 | |
Projekt | Backendservice zur Ermittlung verschiedener Mitarbeiter bezogener Daten | |
Branche | Autowerkstatt | |
Tätigkeit | Architektur, Implementierung | |
Beschreibung | Neuentwicklung eines Spring Boot basierenden Microservices zur Ermittlung Mitarbeiter bezogener Daten aus verschiedenen Backendsystemen. Die Daten werden an verschiedenen REST Endpunkten bereitgestellt. Da die Backend-systeme einen zu den REST Endpunkten abweichenden Business-Key benutzen, wird ein CSV-Dump aus einem Legacy-System bereitgestellt. Dieser wird zyklisch mittels Quartz eingelesen und als Mapping in einer PostgreSQL bereitgehalten. Die Mitarbeiterinformationen werden dann aus einer Oracle DB oder per SOAP/REST von anderen Backendsystemen ermittelt. | |
Ausführung | Linux Java 11, Spring, Spring Boot Kubernetes Docker, Docker compose Quartz, REST, Jackson Hibernate 5, PostgreSQL, Oracle DB, H2 Cloud Mockito Junit, AssertJ IDE: IntelliJ 2018 Vorgehensmodell: Kanban Tools: Maven, Jira, Bitbucket VCS: git |
Formular eMail Service
Datum | 12/2018 – 01/2019 | |
Projekt | Backendservice zum Versand von Formulardaten per eMail | |
Branche | Autowerkstatt | |
Tätigkeit | Architektur, Implementierung | |
Beschreibung | Neuentwicklung eines Spring Boot basierenden Microservices zum Versand von Formulardaten per eMail. Die Daten werden an einen REST Endpunkt angenommen und basierend auf diversen Regeln in unterschiedlichen Formaten an diverse Empfänger versendet. Als Template Engine wurde thymeleaf benutzt. | |
Ausführung | Linux Java 11, Spring, Spring Boot Kubernetes Docker, Docker compose REST, Jackson Cloud Mockito Junit, AssertJ IDE: IntelliJ 2018 Vorgehensmodell: Kanban Tools: Maven, Jira, Bitbucket VCS: git |
Online Terminvereinbarung
Datum | 10/2018 – 12/2018 | |
Projekt | Online Terminvereinbarung | |
Branche | Autowerkstatt | |
Tätigkeit | Architektur, Implementierung | |
Beschreibung | Architektur und Implementierung neuer Funktionen eines Online Terminvereinbarungsservice durch Spring Boot basierende Microservices. Die Kommunikation der Microservices basiert auf REST und Kafka. Daten werden in PostgreSQL gespeichert. | |
Ausführung | Linux Java 11, Spring, Spring Boot Kubernetes Docker, Docker compose REST, Jackson Hibernate 5, PostgreSQL, H2, Kafka Cloud Mockito Junit, AssertJ IDE: IntelliJ 2018 Vorgehensmodell: Kanban Tools: Maven, Jira, Bitbucket VCS: git |
Kommunikationsplattform
Datum | 04/2017 – 09/2018 | |
Projekt | Plattform zum Versand von Nachrichten | |
Branche | Handel | |
Tätigkeit | Architektur, Implementierung | |
Beschreibung | Architektur und Implementierung neuer Funktionen einer auf Nachrichten basierenden Kommunikationsplattform auf Basis Spring Boot. Die gesamte Plattform ist auf diverse Microservices verteilt, die mittels REST und AMQP untereinander kommunizieren. Dabei kommt ein Templatesystem zum Einsatz, was den Klienten den Versand der Nachrichten vereinfacht, da nur ein Minimum an Payload benötigt wird. Das Rendering der Nachricht geschieht innerhalb der Plattform für den jeweils relevanten Kommunikationskanal. Hier wird derzeit SMS, Push (iOS und Android), eMail, Facebook Messenger und Brief unterstützt. Alle Nachrichtenkanäle verfügen über eine vielzahl an Kennzahlen zum Tracken der einzelnen Nachrichten. | |
Ausführung | Apple / macOS / Linux Java 8, Spring, Spring Boot Amazon AWS, EC2 Docker REST, Jackson Hibernate 5, PostgreSQL, H2, redis, RabbitMQ (AMQP) Cloud Mockito Junit, Hamcrest, AssertJ IDE: IntelliJ 2017 Vorgehensmodell: Scrum Tools: Maven, GitHub Enterprise VCS: git |
Rewrite Nachrichtenservice rubbergram
Datum | 02/2018 – … | |
Projekt | Rewrite einer Web-Applikation zum Versand von Einwegnachrichten rubbergram.com | |
Branche | Social Web | |
Tätigkeit | Idee, Design, Implementierung | |
Beschreibung | Einfache Möglichkeit zum Versand von Einwegnachrichten, die beim Lesen automatisch gelöscht werden. Möglichkeit für Attachment als Bild. Bei Erstellung der Nachricht wird ein Link generiert, der dem Empfänger mitzuteilen ist. Ruft der Empfänger den Link auf, so wird die Nachricht auf dem Server gelöscht, wodurch sie nur einmalig gelesen werden kann Microservice Architektur: message store, authorization/authentication, frontend |
|
Ausführung | PC / Windows, Ubuntu Linux IntelliJ IDEA 2018 Java 8 Spring Boot 2, Spring Security, Spring JPA, Spring Cloud Sleuth, Spring Actuator JPA2, Hibernate 5, HikariCP, Flyway 5, PostgreSQL 10 Jackson, MapStruct 2 Logback, Micrometer AssertJ, Mockito Thymeleaf 2, custom dialect, Bootstrap, jQuery |
|
Features | Versand von Tect und Bildern. Benachrichtigung des Versenders beim Lesen der Nachricht. Unterstützung mehrerer Sprachen. Unterstützung von X-Forwarded-* headern zum Betrieb hinter einem reverse proxy zur SSL-Temrinierung. Blockieren der Anzeige beim Versand des Links mittels Facebook Messenger, damit hiermit die Nachricht nicht zerstört wird. Benutzerverwaltung; registrierte Benutzer können zusätzliche Features nutzen. Benutzerregistrierung, recaptcha Integration. Versand von multipart MimeMessage (plain text, html) eMails zur Aktivierung des Accounts nach Aktivierung und Lesebestätigungen. Hierzu wird der bereits vorhandene eMail Server als relay benutzt. Feature switches mit unterschiedlichen Aktivierungsstrategien (Benutzergruppe, Spring-Boot Profil, Administratorfunktion). Integration in Thymeleaf durch custom dialect. Serverseitige Integration durch Annotation mittels AspectJ. Administratorfunktionen: Übersicht der Nachrichten, aktuelle User sessions, Verwaltung von Registrierungen, Verwaltung von Feature switches für aktuelle User sessions (auch anonyme). Connection pooling für message store und auth-service. Distributed tracing. |
|
Betrieb | Metriken mittels Prometheus, Grafana Logging mittels Filebeat, Elastic Search, Kibana Docker compose zur Orchestrierung aller Container (PostgreSQL, message-store, auth-service, frontend, Filebeat, Elastic Search, Grafana, Kibana, Prometheus). |
|
DevOp | GitLab, GitLab CI/CD |
Community Platform
Datum | 09/2016 – 03/2017 | |
Projekt | Suchmaschinenoptimierung und Weiterentwicklung einer Community Plattform | |
Branche | Community | |
Tätigkeit | Architektur, Implementierung | |
Beschreibung | Architektur und Implementierung neuer Funktionen sowie Bugfixing einer Spring basierenden Community Plattform. Architektur und Implementierung einer Sitelist zur Anbindung von Suchmaschinen wie Google auf Basis Spring Boot, welche in der hauseigenen Cloud läuft. Die hier benötigten Scheduling-Aufgaben wurden mit Spring implementiert. Zur Synchronisation der Instanzen wurde redis gewählt. |
|
Ausführung | Apple / macOS / Linux Java 8, Spring, Spring Boot Stripes, JSP, JSTL REST, Jackson mySQL, MyBatis, redis, Elasticsearch Cloud Mockito REST-Assured JUnit, Hamcrest IDE: IntelliJ 2017 Vorgehensmodell: Scrum Tools: JIRA, Team City, Confluence, Maven VCS: git |