CakePHP php Programming

Thoughts on CakePHP, Services, DDD and DI

Recently there has been a lot discussion about “services” and “business logic”, “DDD” and missing “DI” in the CakePHP framework.

For an easy start just let me quote the first paragraph from this page, that pretty much hits the nail in my opinion:

According to Eric Evans, Domain-driven design (DDD) is not a technology or a methodology. It’s a different way of thinking about how to organize your applications and structure your code. This way of thinking complements very well the popular MVC architecture. The domain model provides a structural view of the system. Most of the time, applications don’t change, what changes is the domain. MVC, however, doesn’t really tell you how your model should be structured. That’s why some frameworks don’t force you to use a specific model structure, instead, they let your model evolve as your knowledge and expertise grows.

I think that the framework in fact doesn’t provide any recommendation or template structure for how this could look like when it should. For exactly this topic there is a discussion going on here. Because of a lack of such a structure I’ve started working on a plugin that provides this. The plugin doesn’t require but suggest the usage of DI containers for the people who want them.

But you’re totally free to create a folder structure like

  • /src/Service
  • /src/Model/Domain

and then simply instantiate services as you need them in your controller actions. A service could be for example \App\Service\User\Registration and using objects from App\Model\Domain\User.

Given the whole fancy topic around DI and DDD so far I would say there is not the one way to get things right but different paths as long as the code is easy to maintain. And honestly, as long as this goal is archived I really don’t care about how you call it. 🙂 I think many people tend do make this topic to academic instead of simply trying to be practical.

Not everybody is even needing that structure. It depends on if you’re building a RAD CRUD application or a more complex app. Not every application needs a DDD approach. There are so many shades of gray when it comes to design the business layer, no matter how the framework would do it, somebody would always complain about it.

I personally almost never missed a DI container in CakePHP, not even in the biggest project having more than ~560 database tables which was a hospital management solution and it just worked well.