Wer sicher sein will, dass Software richtig funktioniert, muss sie laufend testen. Das kann man entweder immer wieder manuell tun und entsprechende Kosten in Kauf nehmen, oder man automatisiert die Tests. Die Teilnehmer dieses Workshops lernen, wie sie das Werkzeug PHPUnit, den Standard für Testautomatisierung in der PHP-Welt, in ihren Entwicklungsprozess integrieren.

If you want to be sure that your software works correctly then you need to continuously test it. Automated tests save you from pressing F5 in the browser all the time as well as from using debug statements such as var_dump() in your code. They are also cheaper than manual tests and easier to implement than you may think. How do I test my code with as little effort as possible? How do I execute as few lines of code as possible to test what I am really interested in? And what does this have to do with clean code? Attendees of this session will learn why they should include PHPUnit into their set of development tools.

Event Storming is an emerging group modeling technique using sticky notes and verbal communication that is not only extremely efficient, but also easy to learn, and fun to do. This workshop introduces you to Event Storming with a strong focus on process design. Rather than talking a lot of theory, we will quickly dive into a group exercise and start modeling a real-life business problem, which will lead to valuable insights and is likely to spark off a lot of interesting discussions. We will not stop there, however, but also turn the model into working PHP code using Domain-Driven Design techniques and patterns, so bring your laptop with a working PHP environment. To conclude the day, we will demonstrate how to integrate the code with your favorite framework. This workshop might forever change the way you write code, so do not miss out on it.

Congratulations! You finally managed to convince the business that there really is no way to add this important new feature to the old legacy code base without causing major disruptions. But where to go from here? Completely rewriting the old monolithic application that does a gazillion things from scratch may seem tempting but is a gigantic effort with an unforeseeable outcome. Discover a way out of legacy hell by learning about architectural patterns as well as concrete technical solutions that enable you to gradually move functionality into new software components without the impediments of a full rewrite.

Congratulations, you successfully replaced your legacy monolith. And not just with a distributed monolith comprised of microservices that depend on each other, but rather with an assembly of self-contained systems that do not share infrastructure. There is just one question left to answer: how do you test an application that consists of self-contained systems? Come to this meetup and learn the answer!

Domain-Driven Design (DDD) has become a major trend, maybe even a buzzword. The idea of (more) collaboration between developers and domain experts, however, is not new, but has already been a part of the Agile Manifesto. To be honest, "agile" does not work very well in most companies. We will try to analyze why this is the case, and ponder the question whether DDD can fix that.

Domain-Driven Design (DDD) ist mindestens zu einem Trend, wenn nicht sogar zu einem Buzzword geworden. Dass Entwickler (mehr) mit Fachexperten zusammenarbeiten sollten, ist allerdings nicht neu, sondern steht so schon im agilen Manifest. Nun funktioniert "agil" in den meisten Unternehmen nicht besonders gut, wenn man ehrlich ist. Wir analysieren, warum das so ist, und gehen der Frage nach, ob DDD das reparieren kann.