Rajesh Bhojwani

Yes. First time it will crash. Its expected behaviour based on current design of pcf.

Hi,

I think you have put comments in the wrong blog. I don't have any class named "UserRepositoryController " in this blog. Are you referring it to my other blog? https://dzone.com/articles/elasticsearch-with-spring-boot-application

However, you can use either of findById or findOne. It depends on which version of Spring data elasticsearch you are using. If you go for the higher version, findOne are converted to findOneBy<fieldnames>.

But ensure you read the compatibility issues I shared in the other blog (link above).

I hope it helps.

Nice catch. you are right. It's a typo mistake. Thanks for reading and notifying.

The example I used to cover JPA working with multiple DBs and that's why I mentioned DBs as outside part, not DB Frameworks. If you want multiple frameworks to get work with this architecture, you may need one more layer where Employee will be a simple POJO as inside part and then an adaptor to map that with a POJO (e.g. EmployeeJPA) compatible with JPA or other some other framework and implement accordingly. But that is going to make it overcomplicated your application so again its a trade-off you need to make.

This is a very interesting question. And there is no Black and White answer to it. When you use Annotations, you bring features of the framework to make your code simpler. You can take off the annotation and make it fully inside part and have complicated code around it to work with. So it's a trade-off. I personally don't believe in hard rules and that's the reason I mentioned in my Summary section that it might not be applied for full application. In the Employee example, the purpose was that this can use multiple RDBMS DBs like Oracle, MySQL, etc.. wherever JPA works. Let me know if you have any better way to implement the same.

Thanks for the feedback. Do you have any experience with the Choreography. Please do share with me. I would also like to learn more on the same. What i understood from SAGA pattern is that Choreography and Orchestration are two approaches which can be used to bring consistency when using distributed computing. They cannot be sibling. You should use either of them.

Thanks for the liking the blog.

In my view both DDD and API first approaches are good. And can be applied based on the situation. If i have more clarity on what functionality i need and dont have full clarity of what data model would i be ended up, i will go with API first. If have more clarity on my data model, i will go with DDD. Most enterprise applications will fit with DDD as they have collected data initially and now going with digitization.

Nice thought. My blog size already reached 3k+ words so i had to cut short. I may cover more patterns in next blog.

Nice thought. My blog size already reached 3k+ words so i had to cut short. I may cover more patterns in next blog.

Nice thought. My blog size already reached 3k+ words so i had to cut short. I may cover more patterns in next blog.

Nice thought. My blog size already reached 3k+ words so i had to cut short. I may cover more patterns in next blog.

Nice Question ! I didnt get chance to play much with Service Mesh. However, Pattern wise, both seems to be different. API Gateway is used to expose a business functionality to your consumers. Service Mesh is for internal service-to-service communication. Only network related stuff. Both can co-exist. API Gateway being a gate keeper for Consumers to call your Microservice and Service Mesh for your microservice to call other internal microservice offloading some of the cross-cutting concerns to it. Both have some overlapping features though. I hope it clarifies.