Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bessere Monolithen – modulithische Applikationen mit Spring Boot (Oliver Drotbohm) #10

Open
feststelltaste opened this issue Jul 28, 2020 · 6 comments
Labels

Comments

@feststelltaste
Copy link
Collaborator

@feststelltaste feststelltaste commented Jul 28, 2020

Vorab-Sammlung von Fragen und Beiträgen

URL zum Vortrag: https://cyberjug.de/vortrag/bessere_monolithen/

Hier habt ihr die Möglichkeit, mittels der Kommentar-Funktion vorab Fragen und Beiträge zum anstehenden CyberJUG-Meetup beizusteuern:

  • Was wolltet ihr schon immer über das Thema wissen?
  • Warum findet ihr den Ansatz super oder fragwürdig?
  • Was waren eure Erfahrungen damit?
  • Wo gibt es immer wieder auftretende Diskussionen?
  • ... und vieles mehr!
@feststelltaste
Copy link
Collaborator Author

@feststelltaste feststelltaste commented Jul 28, 2020

Damit es hier nicht so leer bleibt, fange ich schon einmal mit einem (rein beispielhaften) Beitrag:

image

@alexander-dammeier
Copy link

@alexander-dammeier alexander-dammeier commented Jul 28, 2020

Während meiner Bachelorarbeit habe ich eine modularisierte Anwendung, getrennt anhand zweier Bounded Contexts, entworfen und entwickelt. Die Anwendung war natürlich relativ klein, aber um die Architektur zu erhalten, habe ich Tests mit ArchUnit geschrieben.

Meine Hoffnung ist, dass die Entwickler nach mir dadurch daran gehindert werden, mit der Architektur zu brechen.

Details zu den Tests:

Zum einen wird überprüft, ob die Trennung zwischen den Bounded Contexts erhalten bleibt:

public class ModulesArchTest {
    @ArchTest
    static final ArchRule NO_CONTEXT1_IN_CONTEXT2 =
            noClasses().that().resideInAPackage("de.context1..").and()
                    .resideOutsideOfPackage("de.context1.adapterToContext2..")
                    .should()
                    .dependOnClassesThat().resideInAPackage("de.context2..");
    // und umgekehrt
}

Außerdem gibt es jeweils noch Tests für die hexagonale Architektur innerhalb der Bounded Contexts:

@AnalyzeClasses(packages = "de.project")
public class Context1ArchTest {

    @ArchTest
    static final ArchRule HEXAGONAL_ARCH_TEST = onionArchitecture()
            .domainModels("de.project.context1.domain..")
            .applicationServices("de.project.context1.application..")
            .domainServices("de.project.context1.domain.services..")
            .adapter("rest", "de.project.context1.rest..")
            .adapter("messaging", "de.project.context1.messaging..");

}

Frage

Passend zum geposteten Bild wäre meine Frage, ob auf diese Weise nicht eine ähnliche Hemmschwelle zum Architekturbruch gegeben ist, wie bei anfangs gut geschnittenen Microservices. Ich würde mich freuen, wenn im Vortrag ein paar Worte zu solchen Tests gesagt werden, insbesondere wenn es zu dieser Art der Absicherung schon Erfahrungen aus größeren Projekten gibt. Vielen Dank!

@JuliusFaeustel
Copy link

@JuliusFaeustel JuliusFaeustel commented Jul 30, 2020

Wenn wir eine 20 Jahre alte Anwendungslandschaft, die aus mehreren C++ standalone Desktopanwendungen besteht ablösen sollen schreit das auf den ersten Blick nach Microservices. Die Anwendungen haben verschiedene fachliche Kontexte, aber geteilte technische Anforderungen z. B. drucken, aber auch spezielle technische Anforderungen z. B. eine Handscanneranbindung. Wie würde man das Monolith umsetzten? Würde man auch eine Desktopanwendung schreiben? Welche Vorteile entstünden?

@tloist
Copy link

@tloist tloist commented Aug 3, 2020

Geht es um die Modulithen oder eher abstrakter um das gesamte Thema?
Hat sich im Vortrag erledigt: Ja, es ging um Moduliths

@tloist
Copy link

@tloist tloist commented Aug 3, 2020

Wie zieht man seine Modulgrenzen so, dass sie scharf genug sind damit man sie nicht versehentlich übertritt aber nicht so scharf, dass man noch von einem Deployment (einem Monolithen) sprechen kann?
Hat sich im Vortrag erledigt: Eigene "Test-DSL" auf Basis von ArchUnit

@tloist
Copy link

@tloist tloist commented Aug 3, 2020

Was sind Ausschlusskriterien gegen Modulith oder (noch?) bekannte Schwächen auf Basis derer du derzeit einen Einsatz der Bibliothek nicht empfehlen kannst?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.