Sliced Onion Architecture
Autor
Marcus HeldHi,
Vor einer Woche hat Oliver Drotbohm eine erweiterte Idee der Onion Architecture publiziert: The Sliced Onion Architecture .
Hexagonal Architecture und deren Erweiterung die Onion Architecture sind den meisten Softwareentwicklern bekannt. Die Idee (vereinfacht): Man decoupled seinen Businesscode mithilfe von Adaptern von Infrastrukturcode.
Damit ist es weniger wahrscheinlich den “Big Ball of Mud” zu erschaffen.
Was sehe ich in der Praxis?
Die meisten Entwickler haben verstanden, dass es eine gute Idee den Businesscode nicht mit Infrastrukturcode zu vermischen.
Gleichzeitig wollen sie ihre Applikation verteilen. Meist aus den falschen Gründen - aber das ist eine andere Geschichte.
Wenn die Applikation verteilt ist, dann braucht es eine Kommunikationskomponente. Und wenn die Kommunikation regelmäßig stattfindet, dann braucht es ein decoupling mit einer Message Queue.
Die Idee von Oliver geht in diese Kerbe. Wir sehen unsere einzelnen Domänen nicht mehr als vollständige Onion. Es wird zugelassen, dass die Applicationlayer direkt untereinander kommunizieren können.
In der Praxis ist das dann ein einfacher Method-Call oder ein interner Eventmessaging-Mechanismus wie Springs’ ApplicationEvents.
Das ist einfach.
Gleichzeitig haben wir die Freiheit in Zukunft unsere Applikation zu schneiden und unabhängig zu deployen.
Ohne einen Namen dafür zu haben entwickle ich meine Applikationen seit Jahren mit dieser Idee. Es ist die Visualisierung von der ich bisher nicht wusste, dass ich sie brauchte.
Danke Oliver!
Rule the Backend, ~ Marcus