Monolithen zähmen leicht gemacht

Die längste Zeit verbringt ein Projekt in dem Status der Wartung. Jeder, der schon einmal in so einem Wartungsprojekt gearbeitet hat, kennt dieses Phänomen vermutlich. Das Implementieren neuer Features dauert von Sprint zu Sprint immer länger und ist dazu auch noch äußerst fehleranfällig. Die Testabdeckung lässt meistens zu wünschen übrig, und eine einfache Änderung in einer einzigen Klasse führt zu vielen weiteren notwendigen Änderungen in beteiligten Klassen. Wer diese oder eine vergleichbare Situation schon einmal erlebt hat, ist in Besitz des so gefürchteten Big Ball of Mud.

Dieser Vortrag ist genau das Richtige für Sie, wenn Sie eine Schlammschlacht lieber umgehen und Ihre PS wieder auf die Straße bringen möchten. Es wird gezeigt, wie Sie das Dependency Inversion Principle und Java Packages als Mittel zur zyklenfreien (Re-)Modularisierung Ihrer Anwendung verwenden und welchen Einfluss das DIP auf Ihre Architektur hat.

Transcript

1. Monolithen zähmen leicht gemacht http://weltenkreuzer.de/wp-content/uploads/2015/03/handwerk.jpg Bennet Schulz, @bennetelli
 bennet.schulz@codecentric.de
2. Bennet Schulz IT Consultant bennet.schulz@codecentric.de blog.codecentric.de bennet-schulz.com @bennetelli
3. Was ist passiert?
4. Quelle: http://www.stadtlandmama.de/content/no-no-no-jetzt-bitte-scherben-auffegen
5. Was war die Ursache?
6. Quelle: https://www.linkedin.com/pulse/software-erosion-httpsenwikipediaorgwikisoftwarerot-miguel-merayo
7. März 2004
8. Oktober 2004
9. April 2005
10. Mai 2005
11. Mai 2006
12. November 2007
13. September 2008
14. Quelle: https://c1.staticflickr.com/1/722/21473796202_c3076cb3ea_b.jpg
15. Quelle: https://c1.staticflickr.com/1/722/21473796202_c3076cb3ea_b.jpg Erosion stinkt!
16. Quelle: http://www.momentumforimpact.org
17. Quelle: http://www.momentumforimpact.org ändern schwieriger
18. Quelle: http://www.momentumforimpact.org ändern schwieriger alles dauert länger
19. Quelle: http://www.momentumforimpact.org ändern schwieriger testen schwieriger alles dauert länger
20. Quelle: http://www.momentumforimpact.org ändern schwieriger testen schwieriger alles dauert länger „bloß nichts anfassen“
21. Quelle: http://www.momentumforimpact.org ändern schwieriger testen schwieriger alles dauert länger „bloß nichts anfassen“ copy & paste
22. Quelle: http://www.momentumforimpact.org ändern schwieriger testen schwieriger alles dauert länger „bloß nichts anfassen“ copy & paste überall herrscht Angst
23. Was können wir dagegen tun?
24. Quelle: http://www.shutterstock.com/pic-162589649/stock-photo-pastel-isolate-toy-blocks.html?src=LAtnmvYyeCDBHpcf5Nt4jQ-1-34
25. „There should be low coupling between Modules and high cohesion within them.“ Eric Evans
26. Kohäsion hohe Kohäsion innerhalb von Modulen
27. Kopplung lose Kopplung zwischen Modulen
28. Warum macht das nicht jeder?
29. Demo
30. Quelle: http://bigalmanack.com/wp-content/uploads/2016/06/entrepreneur-easy-way.jpg
31. Demo
32. Wie organisieren wir Pakete und Klassen?
33. Nach Fachlichkeiten!
34. de.codecentric. …
35. de.codecentric.web.posts
36. de.codecentric.posts
37. de.codecentric.customer.persistence
38. de.codecentric.customer.entity 
 de.codecentric.customer.control de.codecentric.customer.boundary
39. Wie integriere ich die Analyse in meine tägliche Arbeit?
42. Fazit
43. Nutzt packages als Mittel zur Modularisierung!
45. • http://stackoverflow.com/questions/3085285/cohesion-coupling • https://en.wikipedia.org/wiki/Dependency_inversion_principle • https://en.wikipedia.org/wiki/Software_rot • https://www.linkedin.com/pulse/software-erosion-httpsenwikipediaorgwikisoftwarerot-miguel-merayo • https://structure101.com/blog/2008/11/software-erosion-findbugs/ • https://structure101.com/blog/2008/12/software-erosion-and-package-tangles/ • http://www.adam-bien.com/roller/abien/entry/bureaucratic_design_with_java_ee • http://www.olivergierke.de/2013/01/whoops-where-did-my-architecture-go/ • http://agilewiki.ipponsoft.de/doku.php?id=entity-control-boundary • http://blog.schauderhaft.de/degraph/documentation.html#testing_of_dependencies
46. • Design Principles & Design Patterns, Robert C. Martin, 2000 • http://de.slideshare.net/matthiasnoback/principles-of-package-design-fosdem-2015 • https://en.wikipedia.org/wiki/Software_package_metrics • http://www.codemanship.co.uk/parlezuml/metrics/OO%20Design%20Principles%20&%20Metrics.pdf • http://www.codingthearchitecture.com/presentations/sa2015-modular-monoliths • https://thebojan.ninja/2015/04/08/high-cohesion-loose-coupling/ • http://alvinalexander.com/java/java-law-of-demeter-java-examples • http://www.oodesign.com/dependency-inversion-principle.html • https://de.wikipedia.org/wiki/Dependency-Inversion-Prinzip • http://de.slideshare.net/sandromancuso/how-much-do-we-know-about-objectoriented-programming
47. • https://dzone.com/articles/thoughts-on-coupling-in-software-design? edition=196609&utm_source=Daily%20Digest&utm_medium=email&utm_campaign=dd%202016-08-03 • http://structure101.com/blog/2008/12/software-erosion-and-package-tangles/ • https://www.doag.org/formes/pubfiles/5053658/docs/Konferenz/2013/vortraege/Java/2013-Java- Jens_Schauder-Abhaengigkeiten_managen_mit_Degraph-Manuskript.pdf • http://alistair.cockburn.us/Hexagonal+architecture • https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html • http://www.blackpepper.co.uk/managing-complexity-with-a-hexagonal-architecture/ • http://dontpanic.42.nl/2011/08/the-dependency-inversion-principle.html • http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important