ddd.io

PHPBenelux 2015

Wow, what an exciting couple of days! I'm back from PHPBenelux 2015 and hoping I'll be heading back again in 2016!

As a speaker I was treated to an amazing dinner on Thursday, January 22nd, at Teatro Boxtalino. While some of the European speakers were less impressed (apparently they have many opportunities to have these experiences?!) I had never been to anything quite like it. It made for quite an experience.

The actual conference kicked off on Friday, January 23rd and concluded on Saturday January 24th. The first half of Friday was dedicated to tutorial sessions that were only available to people with tickets specifically for the tutorial sessions.

The sessions themselves were great! The venue was well laid out. It sounds like PHPBenelux has used the same venue for many years and I can see why. It offers a great mix of meeting spaces, hallway track, and ample room for social events.

One interesting thing I noticed was that someone was tweeting drawings of the talks he was attending. I tracked down Peter Decuyper (@sgrame) to let him know I thought it was great!

He ended up going to most of the talks I had picked out for the unofficial DDD track so as a special treat you're going to get to see his drawings to go along with my reviews! Thanks for granting me permission to use these photos for this blog post, Peter!

If you followed the unofficial DDD track at #phpbnl15, let me know in the comments! I'd like to see if this was useful or interesting for people so I can see if it would make sense to do this for future conferences I attend as well.

Lastly, if you attended any of these talks make sure to rate those talks on joind.in!


Task based UIs

Presented by Stijn Vannieuwenhuyse (@stijnvnh)

Resources: slides, joind.in/13112, talk description

Stijn's talk on task based UIs was the first talk I attended of the conference. He started out by offering a brief history showing how progressed form paper forms to the proliferation of computers and why CRUD became so common.

He presented his case for why CRUD is not appropriate anymore. One of my favorite quotes from him was, in speaking to the fact that CRUD is helpful for entering massive amounts of data from paper forms, "all of the data has been entered."

Stijn highlighted some of the technical issues that CRUD introduces, like conflicts with concurrent users, the tendency for CRUD to lead toward coupling to frameworks, databases, and forms.

He also pointed a finger squarely at developers in that we often tend to look at a problem and immediately start translating the problem into CRUD operations.

More subtly, Stijn introduced the notion that CRUD does not allow one to model business processes very well. Sometimes the "why" an update occurs is important and providing a rich relevant sent of options and buttons and workflows can be far more useful to users than simply, "edit."

He asserted that software should guide its users through the business process and not the other way around. If the workflow makes sense for the business process many times the acts themselves are self documenting. If users are presented with relevant options that make sense in their context in specific situations things become a lot easier for users.

Stijn also covered technical and implementation details regarding domain models. As expected, Domain-Driven Design and CQRS were both discussed in decent detail but much of the talk was about why you might want to have task based UIs and not as much focus on the technical implementation.

He also talked about the Command pattern quite a bit. One interesting suggestion he made was having just one command controller rather than having a controller for each specific command. While I'm not 100% sold on this, he did discuss it quite a bit and made a decent case for it.

I thought it was a great talk and think that it would be a great introduction to someone who was interested in task based UIs, have been considering whether CQRS was worth it, or have been looking for good reasons to pitch CQRS on their next project.

I'll close this review with one of my other favorite quotes I took away from it, "if you are building software and you are writing CRUD you are throwing away money."


A Series of Fortunate Events

Presented by Matthias Noback @matthiasnoback

Resources: slides, joind.in/13120, talk description

As expected, this talk was great but not directly relevant to DDD or Event Sourcing. As such, I won't spend too much time reviewing this.

Matthias has a great way of teaching principles of software design. I'd definitely recommend this talk if you are wanting to find out the best way to write your own event system or better utilize a third-party event system.

Matthias also has a new book available, Principles of Package Design. I was lucky enough to get one of the copies that he brought to PHPBenelux! Thanks Matthias! If you're interested in learning how to prepare your code for reuse you should definitely check out this book.


Migrating to DDD

Presented by Anatoly Pulyaevskiy @pulyaevskiy

Resources: joind.in/13169, talk description

This talk by Anatoly turned out to be a pretty decent overview of the core principles of Domain-Driven Design. He told the story of how Sparkcentral decided to try and migrate their system to DDD.

He started out talking about how many projects start. First with a lone developer and an MVP. Then additional developers and features. The key thing being a lack of product management in the early years of a software project: nobody is responsible for "the product."

In the case of Sparkcentral, they found themselves with an incredible product but a product that was not easy to maintain. As a result of tight deadlines and frequent changes to the business requirements they had ended up with a "not just-a-Symfony-project" codebase with a slow and fragile test suite.

Anatoly discussed at a high level many of the core Domain-Driven Design patterns and concepts including a sizable chunk on Ubiquitous Language.

He used an interesting sales pitch for why to use DDD that I had not heard before. Mostly in that you can start using these patterns as ready-to-use conventions that take away some of your decisions for planning. I've seen this reasoning used for why selecting a well-used coding standard should be adopted but I had not considered this for a reason why someone might pick up Domain-Driven Design.

Anatoly discussed the difference between the Model and Architecture, and described Model-Driven Design asking the question, "What does this application do?" He also drove home the point that each has different reasons for change. The Model changes based on business requirements and the Architecture changes based on technical requirements.

By being more domain-centric in your design, and keeping architecture out of the domain, your application can more easily adapt to architecture changes as technical requirements change without impacting the business model.

Anatoly provided a roadmap for embarking on the journey of migrating an existing application to Domain-Driven Design. First, a few assumptions were listed. DDD is best suited for complex domains. In the case of Sparkcentral, they had multiple applications. They decided to focus on just one bounded context at first rather than trying to do more. And they adopted a system of continuos refactoring to keep the project moving.

Step 0 was defining the domain language. This seemed like a reasonable first step. Focus on the small things that have less dependencies and build up from there.

Step 1 was defining the project structure. He called the typical Symfony AcmeBundle a "big ball of mud" and I could not agree more. Move the domain out of the framework and don't let the framework define how you structure your domain model.

There was additional discussion about not relying on the framework's services or the framework's container. This seemed highly opinionated to me and although I can kind of see the point, I don't know that I agree entirely. More on that later.

Step 2 was answering the question of whether they should use Doctrine ORM or not. Sparkcentral opted not to use Doctrine ORM. Instead, they wrote their own. DON'T TRY THIS AT HOME.

Step 3 discussed the question of DI containers. Again, I thought this was highly opinionated but in the context of, "this is how we implemented Domain-Driven Design" I think it was appropriate. Of the various containers they decided to use PHP-DI.

On this point, though, I think it is entirely possible to use the framework's container itself provided you can wire up everything you need and inject it into that same container without the framework.

Step 4 tackled the question of tests. Impressively, Sparkcentral's test suite runs in 7 seconds for all of their unit, functional, and integration tests. The credited this performance to having isolated their domain-model, having a container specifically for the domain, and using in-memory implementations.

Implementing Domain-Driven Design can be a complicated thing to try and show. I think Anatoly did a great job both giving a broad overview of what Domain-Driven Design is and also showing which decisions they faced and how they ultimately chose to implement those parts of the system.


Small Uncontrolled Experiments

Presented by Mathias Verraes (@mathiasverraes)

Resources: slides, joind.in/13174, talk description

The only mention of Domain-Driven Design in this talk by Mathias was, "this talk is not about DDD," so I won't spend too much time reviewing this one, either.

I found this talk to be quite inspiring. It was great to see some of the successes and failures of the experiments that he had been a part of.

Too often I find myself making plans based on assumptions I've never tried out. I can see how this has kept me from learning things I would not have been able to find out otherwise. "In brainstorming you are supposed to generate ideas and create options, not kill ideas."

The "no more sprint deadlines" experiment goes at the heart of one of the issues I've had around the notion of sprints. I like seeing that there are people playing with finding ways around this.

The wall of technical debt sounded like a great idea. The first time you run into technical debt, write it on a sticky. The next time anyone runs into that same debit and it costs them time, put a mark on the sticky. Over time you'll find which technical debit is actually costing you time versus that which is not. "If it works and nobody ever needs to touch it, you don't need to spend time fixing it."


Say What? Ubiquitous Language and You!

Presented by Beau Simensen (@beausimensen)

Resources: slides, joind.in/13183, talk description

The combination of being the last regular talk of the conference and being up against Sara Goleman's "The future of PHP" made for lower turnout for my talk than I had hoped. The group was not too small, though, so I was not disapointed.

The talk itself went rather quickly but the question and answer session took the talk to the full hour mark. I had a number of great questions being asked and in some cases other attendees were able to speak up with their experiences on some of the questions as well. I felt pretty good about this and I was glad that people were comfortable jumping in.

I had a chance to discuss being intentional about employing Ubiquitious Language without explicit buy-in from Domain Experts. It is an idea I'd like to explore more in the future and I'm glad I had the opprotunity to discuss it in more detail with several PHPBenelux attendees who are also practice and discuss Domain-Driven Design regularly.

If you attended my talk, I'd love to get your feedback on joind.in!


There were a lot of people talking about Domain-Driven Design at PHPBenelux this year, both in the talks themselves and in the hallway track, and it seems like the topic is continuing to heat up in the PHP community. I'm glad I could play a part in the discussion at PHPBenelux!

I hope you enjoyed my review. Do you see anything missing? Did you have another DDD, CQRS, or Event Sourcing experience at PHPBenelux outside of these talks? Mention it in the comments!