In a PHP DDD application with a folder structure like this:
app/
views/
controllers/
domain/
models/ ( orm generated )
services/
factories/
what would the following classes represent(from a DDD terminology point of view) and what would be the recommanded location for them.
Dictionary ( basic functionality: checks if a word is valid ) HtmlValidator ( basic functionality: checks if a string is a valid html ) UserCollection ( basic functionality: operations on a collection of users )This doesn't look like a DDD application.
In particular, ORM generated models are not domain models. This is a good thing, if your application core value is in data and you just need to handle CRUD operations.
In a DDD application models comes from the language of the domain expert, that is a person that know that business that your application target as it's his own job but does not know anything about tech.
If your domain expert talks about Dictionaries and UserCollection (quite strange, btw) such classes are actually models. HtmlValidator, almost by definition, is not a business term.
I suggest you to avoid using DDD tecniques if the value of your application comes from technological components. Use DDD only for applications that handle very complex business rules.
edit
Most of times domain models worth (at laest) a separate module. In PHP I would suggest you to bundle it in (at least) a separate package. However using the MVC pattern does not imply to use DDD: you can use MVC for a data driven application, and that's fine. In such case I would put in models only ORM generated classes. In such a scenario I would put all that classes in a controllers/lib folder.
The structure is not bad, but I would rename Models to Entities as in MVC the Model consist of Services, Entities and other types of classes.
Dictionary and HtmlValidator dont have identity and are stateless which means they belong to services.
app/
views/
controllers/
domain/
entities/ ( orm generated )
services/ (HtmlValidator)
factories/
Although it looks like very simple application it does mean that you should not start using the DDD building blocks. Every application grows over time and it is good to start with proper structure to avoid the need to refactor it later.
I a as next thing you should consider creation of some sort of module so you can separate logical parts . Also you could separate Application and Presentation layer from Domain and Infrastructure layer:
app/
views/
controllers/
domain/
module1
entities/
services/
factories/
module2
....
vendor/ (infrastructure layer)
ORM
... (some other 3rd party libs)