I m trying to learn how to make my code better. This way, I try to learn some books and understand them.
I m having some troubles dealing with Domain Objects. From the first year of my IT school, I've learnt to create some UML diagrams, and more particularly class diagrams.
When I need to represent the following user story on a class diagram :
"As a user of the application, I need to list all of my clients"
I can translate it to the following (approximative) class diagram :
One of my business rule is to check that a Client (that ows a contact email property) has a mail formatted with some extension, and a special format.
Dealing with my colleagues, it seemed to be a good idea to store it in a service, so that we can control it in multiple ways, and being able to reuse it in another place of my application.
It's okay for me. But...
If we think all the code with all our constraints and methods in our services, we only have POJO instead of Domain Objects.
My Domain Objects are not less not more than a list of properties, representing a value, probably taken from a storage mechanism, but without having any behaviour, only data.
From my example, I only store email inside of Client class, and I don't have anything other.
So, I need to ask you, in which case will I put some methods and behaviours inside of my domain objects instead of in my services ?
Can you provide me a clear example so that I can understand ?
EDIT : Can you tell me if this makes sense :
From what I've understood, it seems that Application Services are the unique entry point to my domain / infrastructure, poviding APIs. Its role is like "aggregating" infrastructure services and domain services.
Domain services are most of the time "stateless" and provides only way to validate data (business rules ? Specification Pattern ?)
Infrastructure services are here to deal with the outdoor (injecting repository for data access, mailing, sending sms etc...)
Can you validate, or at least provide more informations about this ?
Thanks for your help.