What should CQRS and DDD in PHP look like?

I don’t fucking know. Honestly, I don’t.

// Oh lawd.
class DomainDrivenThingy
{
    // Instead of __construct...
    // must use domain-specific "create"... (ಠ_ಠ)
    public static function create() {...}
}

I know what it can look like and I’ve had some success with that so I want to share that with folks that care to listen.

The problem I see over and over on the web when it comes DDD in PHP is that everyone is wondering whether or not they are “Doing it Right™”. About 95% of the time, folks are trying to understand how to tackle some specific problem in their domain. However, instead of talking about their domain, they bring some contrived example that they think is helpful; represented as a “general problem” that most everybody has dealt with before. They make stuff up because “nobody will understand what’s going on in my domain”. It’s hard to communicate the things people “won’t understand because they don’t work in my organization”. It is! But, if we’re not ready to put forth the effort to describe our own problems, we’re not ready for something like an investment in domain-driven design.

It turns out that framing every problem we have in a more generic question that beats around the bush is a highly ineffective method of discovery. More often than not, the immediate response from the more-informed is, “Well, it depends.” Of course it does!

It depends on the details of your domain.

Domain-Driven Design is a bitch. It really is! If you’re not ready to dive in and ask the hard questions, it’s going to be a rough ride. It is somewhat unfortunate that we, being software developers, have trained ourselves away from empathy. It shows. We consider ourselves technical creatures and we are… and it’s great! But that strength a marked weakness when considering domain-driven design.

Anyway, I’m rambling…

What do I think is missing from the DDD in PHP resource landscape?

I had a conversation with a few folks at an open-space last year at php[tek] about DDD. We decided we wanted to talk about the more technical hiccups that occur when trying to move from a “traditional” method of writing applications towards a domain-driven design. This is the kind of stuff that shows up on forums and message-boards:

How do I handle file uploads with domain-driven design?

How do I do authentication and authorization with domain-driven design?

How do I {do some technical thing that’s been done 100 million times before} with domain-driven design?

I understand where the questions come from, but they have absolutely nothing to do with DDD. These types of questions come from fear of the unknown. You’re trying to do something “new” and folks tell you to “do the DDD” and think, naturally, that there is a formula to it all. Think about the last time you learned a new framework. There are a whole set of idioms that come with one framework or another. There is probably an established “right way” for doing things in that framework.

Now throw that thought away. DDD is not that. DDD is not some framework or tool that you “do something with”.

DDD is the Zen Master. It’s a set of hard lessons that urge you to move away from the technical and focus on the people around you: how they talk, what their needs are. It’s a set of practices built on previous generation exploration and you can see SOLID, GRASP, DRY shining through. It’s a mode of thought.

DUSTIN, YOU’RE RAMBLING!! What’s missing?!?!!

When I was starting to learn what DDD was all about, I had no trouble finding the exemplar “DDD To-do List” or a “DDD Shipping and Reporting Application”. These are great, but they’re purposefully generic. They will never be able to teach someone about all of the questions you need to ask and I admit that’s a very hard thing to do with a GitHub repository. They will never be able to teach how to reason about a problem; how you decide on trade-offs.

What I think would be great is if there was a developer out there that basically kept a journal of development effort made towards a domain-driven project. The idea would be that through development of software, the thought processes behind decisions would be captured by smaller posts that were focused around a specific problem. It’s almost like a software diary.

So. I don’t think I’m that developer, but you know what? I’m going for it. The worst thing that could happen is someone who is more knowledgeable than I says that I’m wrong and then we journal on how to course-correct.

The community still profits! Next up is an announcement of what I’ll be working on. I think you’ll like it! I'll try to keep future posts more focused.

This post is raw as hell and I’m leaving it. I did one pass of editing over what was essentially stream-of-consciousness. I’m not a writer and if I’m going to be documenting development towards some project, I’ll get better. It’ll be neat to look back at these at the end and cringe.