I'm developing an Java Web Application with Spring, and I have some questions about my architecture. Before showing it, here is the context:
- I am developing a web application with more than 80 existing tables in the database.
- Both the application and the database are on the same server machine.
- My application will grow in the future so that, if necessary, the database will be inside a machine alone, and the web application will access it from another.
- Now I do everything, but in the future I will have specific professionals in their respective areas and / or layers working side by side with me.
- (EDIT) I am developing the system from scratch, and therefore, I am responsible for modeling and preparation of the database. In short: I'm doing everything alone.
Here is a general model of my architecture:
There are certain points that I would like to comment (for clarification):
- The main components were highlighted in white, as SERVICE, DAO, etc. These components communicate by exchanging data with each other, and perform actions.
- The components in green and gray represent types of data exchanged among the main components.
- The architecture shows a separation into layers.
In relation to this presented model, I have some questions:
- 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)?
- 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.
- 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?
- Finally, is this architectural model wrong for what I want to do? Is there something that needs to be fixed?
Just to be clear, with this organization, I could effect the following situation:
This scheme / diagram shows how a call would be from a control to a DAO (in case, a user control to a UserDAO).
It is seen that I can choose, for example, with Inversion of Control which persistence implementation I wish to use. I like to know if there is also something wrong here
Note: I'm not looking for a correct way. I know how things are. I am looking to complete this model, and whether it is applicable to what I want to do, taking into account the system maintenance, and the capacity of uncoupling of its components. Just it.
So... After much thought, research, and break my head with it, I think I could finally come to a conclusion:
- I'll just kill myself...
... Nah, just kidding! Here's the conclusion:
Each balloon in each component is a introduction of the component itself, revealing their responsibilities. This may seem silly, but it nicely expresses the differences in responsibilities between each one.
In some situations it is not possible to generalize. Not always a service returns a DTO. Similarly, it is not always a service needs simple parameters to carry out an action. Therefore the exchange of data between control and service may vary.
The Application Layer and Business Layer can be the same thing, the same system running on the same server machine. One day you may want to separate things. You may want to turn the Business Layer on a Web Server, useful when you might want to use more than one type of client application to use the services of that particular business.
With code generation tools, you can generate in a matter of minutes things like:
- Domain Model Entities.
- Form Objects (classes).
You can also generate DAO classes with the same tools, but from what I saw, they will not be complete, and will need revision. Service classes are incredibly particular to each case. I believe there is no tool for generating this type of code, and therefore, they need to be written from scratch.