Flup geht in die richtige Richtung. Das "Prinzip der einheitlichen Verantwortung" galt ursprünglich für Verfahren. Zum Beispiel würde Dennis Ritchie sagen, dass eine Funktion eines tun und es gut machen sollte. Dann würde Bjarne Stroustrup in C ++ sagen, dass eine Klasse eines tun und es gut machen sollte.
Beachten Sie, dass diese beiden Regeln, außer als Faustregeln, formal wenig oder gar nichts miteinander zu tun haben. Sie bieten nur das, was in der Programmiersprache bequem ausgedrückt werden kann. Nun, das ist etwas. Aber es ist eine ganz andere Geschichte als die, mit der Flup fährt.
Moderne (dh agile und DDD) Implementierungen konzentrieren sich mehr auf das, was für das Unternehmen wichtig ist, als auf das, was die Programmiersprache ausdrücken kann. Das Überraschende ist, dass die Programmiersprachen noch nicht aufgeholt haben. Alte FORTRAN-ähnliche Sprachen übernehmen Verantwortlichkeiten, die zu den wichtigsten konzeptuellen Modellen der Zeit passen: die Prozesse, die auf jede Karte angewendet wurden, während sie den Kartenleser durchliefen, oder (wie in C) die Verarbeitung, die jeden Interrupt begleitete. Dann kamen ADT-Sprachen, die so weit gereift waren, dass sie erfassten, was die DDD-Leute später als wichtig neu erfanden (obwohl Jim Neighbors das meiste davon herausgefunden, veröffentlicht und 1968 verwendet hatte): das, was wir heute Klassen nennen . (Sie sind keine Module.)
Dieser Schritt war weniger eine Evolution als ein Pendelschlag. Als das Pendel zu Daten schwang, verloren wir die FORTRAN-eigene Anwendungsfallmodellierung. Das ist in Ordnung, wenn Sie sich in erster Linie auf die Daten oder Formen auf einem Bildschirm konzentrieren. Es ist ein großartiges Modell für Programme wie PowerPoint oder zumindest für seine einfachen Operationen.
Was verloren gegangen ist , ist die Systemverantwortung . Wir verkaufen keine DDD-Elemente. Und wir haben keine guten Unterrichtsmethoden. Wir verkaufen Systemverantwortlichkeiten. Auf einer bestimmten Ebene müssen Sie Ihr System nach dem Prinzip der Einzelverantwortung auslegen.
Wenn Sie sich also Leute wie Rebecca Wirfs-Brock oder mich ansehen, die früher über Klassenmethoden gesprochen haben, sprechen wir jetzt über Anwendungsfälle. Das verkaufen wir. Das sind die Systemoperationen. Ein Anwendungsfall sollte eine einzige Verantwortung haben. Ein Anwendungsfall ist selten eine architektonische Einheit. Aber alle versuchten so zu tun, als ob es so wäre. Erleben Sie zum Beispiel die SOA-Leute.
Aus diesem Grund freue ich mich sehr über die DCI-Architektur von Trygve Reenskaug, die im obigen Lean Architecture-Buch beschrieben ist. Es verleiht dem, was früher eine willkürliche und mystische Ablehnung der "Einzelverantwortung" war, endlich eine wirkliche Gestalt - wie man in den meisten der obigen Argumente findet. Diese Statur bezieht sich auf menschliche mentale Modelle: Endbenutzer zuerst UND Programmierer zweitens. Es bezieht sich auf geschäftliche Anliegen. Und fast zufällig kapselt es den Wandel, wenn Flup uns herausfordert.
Das Prinzip der einmaligen Verantwortung, wie wir es kennen, ist entweder ein Dinosaurier, der seit seinen Anfängen übrig ist, oder ein Steckenpferd, das wir als Ersatz für das Verständnis verwenden. Sie müssen einige dieser Hobbypferde zurücklassen, um großartige Software zu entwickeln. Und das erfordert ein Umdenken. Die Dinge einfach und leicht verständlich zu halten funktioniert nur, wenn das Problem einfach und leicht verständlich ist. Diese Lösungen interessieren mich nicht sonderlich: Sie sind nicht typisch und die Herausforderung liegt nicht darin.
