The question arises what your UI is using to get the data and how it sends the data to be persisted. I'm afraid since you mentioned you have no service layer and you suffer with finding the right place for your validation, that your UI works directly with your domain classes. That could be the way to go, however it does not sound like a very complex application and you can do persistance work and querying right in the UI code. You can check posts of Ayende Rahien and many others who talk about getting rid of repositories. In relatively simple scenarios ORM is capable to provide enough isolation of domain model from the persistance itself. Also it is a questionable matter if modern ORMs can be seen purely as DAL. Look at NHibernate, it can do so much more than just mapping simple tables to simple classes. And if you look at your repositories you might find a bunch of methods called GetByThis and GetByThat, which issue a simple query to the ORM (if you use one of course) and just play a silly role of unneeded abstraction to make an impression that you do DDD.
Concerning your comment about "not creating" dependencies by injecting repositories - you will onvert control but you will have dependency as soon as you use repository class instance in your domain object. It does not matter how it gets there. So this is the worse choice of all.
To your validation question I would recommend you to look closely to your validation as such and decide what validation is domain specific and what is more data entry specific. Data entry validation like mandatory fields should not be checked by the domain model. It is a simple job and UI layer is perfectly capable of doing that. Even more, most of modern UIs are able to do this validation very easily. However you need to find a way to inform your UI about the data input rules (I will get back to it below). Your domain model need to perform more business-oriented validation, like if customer with such name already exists. But you, again, cannot do this inside your domain class since you are unable to query existing data from there because it is not the domain object responsibility to care about anything outside of its own aggregate.
So if you want to go to deal DDD journey I would recommend you to look at CQRS principle. It is often bound to event sourcing but you can just skip that. Concentrate on this scenario, when using RDBMS with or without ORM or NoSQL for persistence:
- Create input models and view models to be used solely by the UI.
- Decorate your input models with data attributes for client-side validation.
- Send commands from the UI to your backend to do business validation and persistence.
- Send queries to your backend from the UI to get the data to show. Returned data should be placed in view models.
- Use domain events to communicate between different bounded contexts
It does not necessarily require the backend logic to be put in an application server (although it is very desirable to enable having multiple UIs with the same backend). You can use in-memory events to send commands and queries too.
But again, look at what you really need, don't try to overscale your abstractions just because the book says so. Remember that very often abstractions are put in place just because someone heard this is a good thing. Repositories is a classic example, when people say it makes their system persistence ignorant and they can change their ORM but in fact no one does that. When ORM is changed it means almost full redesign and repositories get scrapped equally well together with all other code.
