I am having a long-term debate with my architect about architecture choices. The entreprise where I work in is migrating from a monolithic architecture to a microservices one.
The debate is located on the good approach for handling database access. One of us is standing there is no need for separating DAO and service (database access are directly handled by the service class), and the other stands for the contrary.
We are discussing about it for days, and I can't find good reason for convincing him, and he cannot either convince me.
The question is actually really simple: in an atomic REST microservice (a microservice handling only one REST method), should we have a separate DAO class or not? Which arguments could you give for separating, or keeping everything together?
This is a OOP oriented project (Java), if it matters.
Edit: This quest has been reposted on softwareengineering
Related
I am working on 2 micro-services currently, microservice A includes microservice B's SDK to call B's API and access some entity classes.
Similarly microservice B also includes microservice A's SDK and accesses microservice A's enitity classes.
Now I am facing one issue when I need to bump up the version of microservice B in microservice A and vice versa.
How should I solve this problem?
You've already broken the cardinal rule of microservices by tightly coupling the two services.
The right answer here is going to be to refactor these services such that they properly and completely encapsulate functionality. That could involve combining them (if B is always and completely dependent on A, they may not really be separate services), splitting them out into more services, or just shifting responsibility.
But, the path you're on with tight-coupled microservices leads to a distributed monolith which is unlikely to provide the benefits you're after (specifically including the co-dependent revision concern you mention here).
Here's a good answer to a related question that might offer some more insight.
I have 3 micorservices one that serves request from UI and the other that serves request from public apis and the third which does some data processing and storing the data provided from the kafka topic by UI/public.
I have written common service and dao jar for the services, as the data is coming from the common data source.
If I dont have common service/dao then lot of code will be duplicated.
I am now feeling that this is causing coupling between the services.
Is it the right design?
Using a common DAO across microservices is right if it is making development faster and easier to understand for everyone, and wrong if it's not. You are right that this is creating some coupling between the services, but it's coupling that you could easily do away with if the DAOs for the services began to diverge. Since the final shared package will be inside each service's runtime, there would be zero issues introduced if one of the other services decided to stop using the DAO and use a different one.
That being said, you may have a larger coupling issue if all three services are using this DAO to connect to a shared database. If each is dependent on the same tables/schema, it makes it very hard for one service to diverge from the others and make independent schema changes without impacting the others.
This question already has answers here:
Why do we need service layer?
(5 answers)
Closed 2 years ago.
I am working on a project which has slightly different design. In all tutorials basically there are POJOs which are representing Models and all the business logic are implemented in service layers. In my project it is implemented in a way that there is not service layer and all the logic are implemented in Model classes by defining some static methods. Some says that it is because of Domain Driven Design but I am not really sure about it.
Putting all the logic inside of the POJOs looks messy for me. I would like to understand what is the benefit of this design and is if it is good software practice to implement business logic without service layer ?
It is definitely a bad idea to use a bunch of static methods, also adding logic in the DTOs is not recommended.
There is not a strict universally accepted rule about creating a service layer, I think what is very important is that the application design is modular and testable.
This is why the service layer pattern comes in handy:
business logic is confined in a layer where you can abstract the complexity into a set of functionality made available to the other layers
application logic is not scattered across packages and classes, simplify the evolution and make possible to refactoring for accommodating future changes
service classes can be tested independently (again critical for refactoring)
I am being working with both Grails and Spring enterprise applications, I know the importance of Program for interface, but I seen most of Grails application are not following this mentioned design, rather their programming flow would be like controller -> service in the service layer they handle all the business and DB oriented things.
But when the same developer's programming style in Spring is emphasizing the importance of Program for interface
Why Grails don't following such design patterns, any reason?
By Program for interface I presume you mean program to an interface. This is a good practice whenever crossing a boundary that is significant to your design. The art is in deciding what is significant.
Using a framework does not force you into a particular pattern or architecture. The framework does change what is convenient. Some people get lured in by that convenience and lean heavily on the framework everywhere they can. Others rebel against this and think of it as lazy coding. In the end it's a trade off.
There has actually been considerable debate on this. I have previously summed that up here
What are the advantages and disadvantages of the Session Façade Core J2EE Pattern?
What are the assumptions behind it?
Are these assumptions valid in a particular environment?
Session Facade is a fantastic pattern - it is really a specific version of the Business Facade pattern. The idea is to tie up business functionality into discrete bundles - such as TransferMoney(), Withdraw(), Deposit()... So that your UI code is accessing things in terms of business operations instead of low level data access or other details that it shouldn't have to be concerned with.
Specifically with the Session Facade - you use a Session EJB to act as the business facade - which is nice cause then you can take advantage of all the J2EE services (authentication/authorization, transactions, etc)...
Hope that helps...
The main advantage of the Session Facade pattern is that you can divide up a J2EE application into logical groups by business functionality. A Session Facade will be called by a POJO from the UI (i.e. a Business Delegate), and have references to appropriate Data Access Objects. E.g. a PersonSessionFacade would be called by the PersonBusinessDelegate and then it could call the PersonDAO. The methods on the PersonSessionFacade will, at the very least, follow the CRUD pattern (Create, Retrieve, Update and Delete).
Typically, most Session Facades are implemented as stateless session EJBs. Or if you're in Spring land using AOP for transactions, you can create a service POJO that which can be all the join points for your transaction manager.
Another advantage of the SessionFacade pattern is that any J2EE developer with a modicum of experience will immediately understand you.
Disadvantages of the SessionFacade pattern: it assumes a specific enterprise architecture that is constrained by the limits of the J2EE 1.4 specification (see Rod Johnson's books for these criticisms). The most damaging disadvantage is that it is more complicated than necessary. In most enterprise web applications, you'll need a servlet container, and most of the stress in a web application will be at the tier that handles HttpRequests or database access. Consequently, it doesn't seem worthwhile to deploy the servlet container in a separate process space from the EJB container. I.e. remote calls to EJBs create more pain than gain.
Rod Johnson claims that the main reason you'd want to use a Session Facade is if you're doing container managed transactions - which aren't necessary with more modern frameworks (like Spring.)
He says that if you have business logic - put it in the POJO. (Which I agree with - I think its a more object-oriented approach - rather than implementing a session EJB.)
http://forum.springframework.org/showthread.php?t=18155
Happy to hear contrasting arguments.
It seems that whenever you talk about anything J2EE related - there are always a whole bunch of assumptions behind the scenes - which people assume one way or the other - which then leads to confusion. (I probably could have made the question clearer too.)
Assuming (a) we want to use container managed transactions in a strict sense through the EJB specification then
Session facades are a good idea - because they abstract away the low-level database transactions to be able to provide higher level application transaction management.
Assuming (b) that you mean the general architectural concept of the session façade - then
Decoupling services and consumers and providing a friendly interface over the top of this is a good idea. Computer science has solved lots of problems by 'adding an additional layer of indirection'.
Rod Johnson writes "SLSBs with remote interfaces provide a very good solution for distributed applications built over RMI. However, this is a minority requirement. Experience has shown that we don't want to use distributed architecture unless forced to by requirements. We can still service remote clients if necessary by implementing a remoting façade on top of a good co-located object model." (Johnson, R "J2EE Development without EJB" p119.)
Assuming (c) that you consider the EJB specification (and in particular the session façade component) to be a blight on the landscape of good design then:
Rod Johnson writes
"In general, there are not many reasons you would use a local SLSB at all in a Spring application, as Spring provides more capable declarative transaction management than EJB, and CMT is normally the main motivation for using local SLSBs. So you might not need th EJB layer at all. " http://forum.springframework.org/showthread.php?t=18155
In an environment where performance and scalability of the web server are the primary concerns - and cost is an issue - then the session facade architecture looks less attractive - it can be simpler to talk directly to the datbase (although this is more about tiering.)