I am DDD practitioner and I was doing DDD Lite and full DDD in few projects already.
I know how many PHP developers creating crappy code so I was really happy about the book and sample project. I've spend some time going through the code, because I wanted to see what
advices, concepts are given and to contribute, if needed.
I've checked the book and need to say it's very good, but I can't say the same about the project.
Let's start from the beginning.
DDD should be used for
non trivial domains to solve. The problem that is taken for the project is just a little bit more than
CRUD. Looking at the code, we may see that it tries to hack reality by solving easy problem with a lot of layers and creating complexity in the places where it's not needed.
I am sure, that it will bring value for a lot of people, but
possibility to learn solving non trival domains for PHP developers is lost in here.
Next thing. I've forked the project and I was pretty sure everything will work like a charm. It's sample project to show ideas from the book, so it had to work.
First I had configure the project, but I was okey with it. I checked what is needed and wasn't really happy to install dependencies on my host machine. So I spend a little time on automatic it with docker.
When I've finished I could run the app, but the app didn't worked. Application
was just throwing exceptions on me. This is just really bad, that app that is about sharing the knowledge, can't be even run, because of exceptions. When I've fixed them (MR in queue), I had a chance to check out the code and I really didn't liked what I saw.
What I've faced except the not working application was:
1. No tests - I am really disappointed about this one. As this book is for developers who really want to learn they should be provided with best examples. Not having tests in the project is like waiting for catastrophe. The project has bugs in such simple domain and it's only, because of the lack of tests. There should be unit, integration, functional tests so people can know how to write them.
2. DomainEventPublisher in model - This makes the model untestable and coupled with higher level abstraction.
3. new DateTime throwed everywhere - Again makes the model untestable and breaks the SOLID.
4. High couplings between upper layers and domain. WishEmail extending Wish, now whenever domain object is changed infrastructure object need to be also changed. It also breaks the SOLID.
5. Configuration available within email sending class. Let's say the WishEmail is good solution. WishEmail doesn't receive info how to send email from outside, but is responsible for it.
The next problem with it is that login and password is provided within the class. (I hope you changed it btw). Such stuff should always be injected.
6. Lack of examples with Value Objects. The only one created within the project is Id. Email is like one of the most popular VO, why not use it?
7. Aggregate root should hold transaction boundaries. In here it doesn't. Why wish is connected with user?
8. Aggregate root is burden with all this php global functions like trim, strtolower. If it need to be used, use it within Value Object for example email.
9. No Docblocks. In PHP 5, we can just guess, what should be provided within function for example.
Having docblock, should be must in all projects and especially ones like this
10. The domain model is pretty anemic, but this may be because of lack of hard problem to solve
There are things, that I liked like translation services, repositories and well separated modules. But I just expect much, much more from DDD leading book for PHP.
Hope, my insights will give you some guidance to increase the value of the project. :)