The green components represent doubts / confusion. Those with "???", are data types that I do not know. What types of data should I put here? Do I need a translator for this (to exchange the correct type)?

This is a quite a matter of taste, personaly i don't like using DTO, because they mainly duplicate business classes make writing adapter, and mess a lot with features like lazy-loading. Furthermore, every time i need to add a field, i need to add it everywhere and retest the whole thing.

So what i did is having only Business Model and i put every annotation i needed (jpa/jackson) on it.

YES this bind my business model to jpa/jackson, as my application rely heavily on Spring, but well decoupling all of that will add quite a lot of work for something that just won't change. I may add later if i need something else (XML serialization) either others annotation or finaly a DTO layer just for this. This will depends of the complexity of the thing.

Is the other type of written data ("DOMAIN MODEL ENTITY" - this is a JPA entity, @Entity) correct? I believe a DAO layer should only be concerned with these types of objects, making it completely independent to care.

As said before, if you want to use the full power of JPA, don't. Here is question of mine on stackoverflow which i was told the same thing, because abstracting JPA leads to unnecessary complex and inefficient code : http://stackoverflow.com/questions/37811139/good-usage-of-managed-entities-proxies-with-orm

I know a DAO type should only be concerned with a single entity, so the query parameters are always their fields / attributes / properties. However, what happens when I have to search for an entity that I need a parameter present in one of it's relationships? For example, search for all users with purchases made last month that had a value greater than X? In this case, I need the details found in the Purchase entity. Do I put this in DAO? And if I have to put it in a service class, I have to set EntityManager inside service also, giving it one more responsibility, which may leave without purpose the DAO persistence layer?

Your DAO layer is by definition aware of the relationships of your model. So of course he can query on subfields and so on. Following what i've been told i considered my DAO layer to be the Entity Manager, so i only have a service layer this fit as long there is nothing too much specific about your DAO/Service.

Finally, is this architectural model wrong for what I want to do? Is there something that needs to be fixed?

As i said, i did some things differently however your model is good because :

• DAO only handle persistency and no business logic/transaction.
• Service handle business logic and transaction.
• Controller do not handle business logic and transaction.

You have the right bases.

The green components represent doubts / confusion. Those with "???", are data types that I do not know. What types of data should I put here? Do I need a translator for this (to exchange the correct type)?

This is a quite a matter of taste, personaly i don't like using DTO, because they mainly duplicate business classes make writing adapter, and mess a lot with features like lazy-loading. Furthermore, every time i need to add a field, i need to add it everywhere and retest the whole thing.

So what i did is having only Business Model and i put every annotation i needed (jpa/jackson) on it.

YES this bind my business model to jpa/jackson, as my application rely heavily on Spring, but well decoupling all of that will add quite a lot of work for something that just won't change. I may add later if i need something else (XML serialization) either others annotation or finaly a DTO layer just for this. This will depends of the complexity of the thing.

Is the other type of written data ("DOMAIN MODEL ENTITY" - this is a JPA entity, @Entity) correct? I believe a DAO layer should only be concerned with these types of objects, making it completely independent to care.

As said before, if you want to use the full power of JPA, don't. Here is question of mine on stackoverflow which i was told the same thing, because abstracting JPA leads to unnecessary complex and inefficient code : https://stackoverflow.com/questions/37811139/good-usage-of-managed-entities-proxies-with-orm

I know a DAO type should only be concerned with a single entity, so the query parameters are always their fields / attributes / properties. However, what happens when I have to search for an entity that I need a parameter present in one of it's relationships? For example, search for all users with purchases made last month that had a value greater than X? In this case, I need the details found in the Purchase entity. Do I put this in DAO? And if I have to put it in a service class, I have to set EntityManager inside service also, giving it one more responsibility, which may leave without purpose the DAO persistence layer?

Your DAO layer is by definition aware of the relationships of your model. So of course he can query on subfields and so on. Following what i've been told i considered my DAO layer to be the Entity Manager, so i only have a service layer this fit as long there is nothing too much specific about your DAO/Service.

Finally, is this architectural model wrong for what I want to do? Is there something that needs to be fixed?

As i said, i did some things differently however your model is good because :

• DAO only handle persistency and no business logic/transaction.
• Service handle business logic and transaction.
• Controller do not handle business logic and transaction.

You have the right bases.