Otavio Santana

Hey Mikhial, thanks for the question.

In the first version, we don't have it.

But in version 1.0.1, we have a plan, including preparing statements

Thank you, Danil. I will include this topic in a video where I go deep into the version.

For now, the easy way is to include it in the URL, for example:

* v1/people/{id}

* v2/people/{id}

You’ve raised some excellent points! This article focuses on getting started with Quarkus using a simple CRUD example.

While Quarkus provides tools, it does not enforce architectural decisions. Developers are responsible for maintaining clean design and separating domain logic. Thank you for your constructive feedback!

You can check the customization here: https://quarkus.io/guides/rest-data-panache#adding-additional-methods-to-the-generated-resource

Hey, how are you?

I am glad that you enjoyed it.

1) How is the evaluation process done by the industry?

The industry values contributions based on code quality, impact, and engagement in discussions like PRs and issue tracking.

2) Is there any guide to support us when we are defining the scope to build something really valuable?

Most projects have contribution guides, and a good start is working on documentation, tests, or small fixes aligned with project needs.

3) What are our responsibilities for this work, is there a time limit or I can do them on my free time?

You can contribute in your free time without strict deadlines, but consistency helps build credibility in the community.

4) How much time this open-source project is published in DZone?

This project has been featured in multiple DZone articles, including my latest on open-source contributions in 2025.

You're welcome, Gopola. I am super glad it was helpful to you.

Thank you for reading as well.

Hey Rumbero, I am glad that you enjoyed it.

The

Correct use of HTTP commands

Please check the glory of rest, the second level; it will bring you a better context of this:

https://martinfowler.com/articles/richardsonMaturityModel.html#level2

Advance URL usages like /expeditions/1/items (When you want to get all items of some concrete expedition)

This one is worth a whole article; the second chapter of the Book Rest API: Design Rulebook by Mark Masse brings several rules worth reading and applying in your project.

https://www.amazon.com/dp/1449310508/

Hey Marcel, I am glad that you enjoyed it.

The full sample is here: https://github.com/o-s-expert/java-videos-code/blob/main/2024/04-pmd-checkstyle/pom.xml#L224
you can take a look, if you need any help, please let me know,

Hey Florian, thanks for your points.

1. When I talk about DDD, my main focus is on the domain and subdomain concepts that belong to DDD; you can check the classic book in Chapter 2.

2. Value Objects belong to DDD; check chapter 5 of the classic book: https://www.amazon.com/dp/B00794TAUG/, which is super valid.

3. If the UUID is used as an ID, you know which information the user was searching for and the return. The UUID is a sample, you can free for using any ID types, such as, Long, String, etc.

You're welcome Manek.

I am super glad that you enjoyed it and it was useful for you.

Thank you, and I am glad that you enjoyed it.

Thank you for your opinion.

Indeed, simplicity is hard to trust, mainly because we have a complexity bias. We start to realize it with time and experience.

It is expected to feel more confident with a thousand layers and interfaces because you might need them in the future instead of doing what you need and then refactore the code.

If I can use a picture, I would use this:

Use when it makes sense; don't try to put several layers because it is cool, and focus on simplicity.

> But how a new implementation of a service might be provided, given that the service doesn't have an interface and, hence , it isn't even a service ?

The simple answer: is refactoring. With the code provided, a good test, and documentation, you can extract the interface. Modern IDE can help you to do it as well.

> I would be curious to understand how do you think to use the template one, without interfaces ?

The interfaces are a requirement. But please, don't use all the patterns all the time. My point is: to use it when it is needed.

> how do you deal with functional interfaces?

It makes to use, thus, use it.

Yes, you can use interfaces and explore patterns without overengineering

What is easier:
See the future or refactor the code and put interfaces when needed?

I am not against interfaces, but I don't believe that all applications need SPI, thousands of interfaces, and several layers; just because Netflix or other companies do, it does not make sense either.

My point is the balance, and yes, I spent more time putting into tests and documentation instead of creating an interface because you might need it in the future.

Thank you, I will fix it, ASAP.

That is the code designer dream!

I am glad that you enjoyed it.
For now, I used this formula to migrate 45 microservices.
So far, so good.

You are right!
Thank you for bringing this up!

Indeed, the balance is crucial.

Thank you, Ronaldo; I am glad that you enjoyed it.

Thank you for your valuable feedback; I genuinely appreciate it. Your mention of several annotations in the Lombok framework brings up some critical points.

As I mentioned, working with any framework involves trade-offs, and Lombok is no exception. Every design and architectural decision comes with its set of advantages and disadvantages.

One significant concern I have pertains to using the Data annotation in Lombok. This annotation, while convenient, has the potential to break the principles of encapsulation that are fundamental to Object-Oriented Programming (OOP). In traditional OOP, we emphasize the concept of hiding data and exposing behavior, encapsulating data within classes to maintain data integrity and control access. The Data annotation, however, tends to encourage an anemic model, where data and behavior are separated. It can lead to data inconsistency issues because it blurs the boundaries between data and behavior.

It's important to note that frameworks like Lombok can sometimes misguide developers by providing convenient shortcuts that may not align with best practices. I recommend using IDE templates or other tools that promote a more explicit and maintainable code structure in cases like these.

Again, thank you for the feedback.

Hey, thank you for your feedback.

I hope to get better in the following video.

The emphasis on modern API design has undeniably shifted towards declarative APIs. This approach is rooted in the idea that APIs should prioritize safety and actively prevent developer errors. As software engineers, we must grasp the trade-offs inherent in the frameworks we use. Problems stemming from inadequate encapsulation can potentially lead to security vulnerabilities, and it's worth remembering that in the realm of security, we adhere to the CIA triad, where 'C' stands for consistency.

I strongly encourage you to delve deeper into object-oriented programming (OOP) principles and explore classic literature like "Clean Code." These timeless resources champion the primary objective of concealing intricate details while exposing desired behaviors.

It's essential to recognize that if an API guides a developer toward a mistake, we should seriously question whether it makes sense to include such a feature. Sometimes, these seemingly helpful additions can inadvertently act as auto-destruct buttons, leading to unexpected consequences. Thus, carefully evaluating an API's design and its potential impact on developer actions is paramount to ensure its effectiveness and safety.

Again, super thank you for the feedback.

Optional in Java it still WIP, since Java 11, it has made several progress.

Optional is a good tool, but there is no silver bullet.

In the end, we are talking about trade-offs.

Hey Jasper.

Thank you, I included this book on my list. This one will be my next.

That is my pleasure, always.

Those are great points; thank you for sharing.

Good point, thank you.
I'll request an update.

Hey, Robert. Thank you for your comments.

I don't follow your "security". Could you explain better?

But if you look at the CIA triad and the ISO/IEC 27001, you'll see integrity and consistency.

Does encapsulation help with consistency?

Does encapsulation help avoid leaks in the application?

If you look at clean code by uncle bob, you'll see the expression "OOP hide data to expose behavior" and guarantee that you don't have an inconsistency in your application, such as a null item in a list is a sample of it.

The point is, you're right. A good encapsulation helps with knowledge, abstraction, and expressiveness. Furthermore, it helps with consistency and data integrity on some occasions. Those are not exclusive but inclusive.

I'm glad that you enjoyed it.

It has been updated, please check it now.

Thank you.

Hey Nicolas.
Thank you for sharing.

It is a good one.

You're welcome.

Thank you, I'm glad to hear it.

Thank you.

Thank you.

Yeap, this is one solution to move away from the reflection, with the same API, so with annotations.

We've changed the issue to compilation time from the runtime.

You're welcome.

Thank you :)

Yes, I know, and I have this feeling. Migration to Java 11 from Java 8 is a colossal pain, mainly because of the modules.

The good news is several Java EE/Jakarta EE vendors have support in Java 11. Furthermore, the next version in July will release with Java 8/11 as a minimum requirement.

What I did to migrate as keep in the maven as Java 8 while I compiled with Java 11. And I did step by step to relocate; I did not move in a huge step.

Now, JSF still alive.

There is a group around that you can join if you wish:

https://jakarta.ee/specifications/faces/

Furthermore, there are several libraries such as primefaces that has released the latest version this month:

https://mvnrepository.com/artifact/org.primefaces/primefaces

Please check with the dependencies that I sent to you.

I checked from the documentation:

https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/jms/support/converter/MappingJackson2MessageConverter.html#setTargetType-org.springframework.jms.support.converter.MessageType-

Hey, I'm glad that you liked it.

Yes, I have it in a repository:

https://github.com/platformsh/java-quick-start/tree/master/spring/spring-jms

Please, let me know if there is any further question. I'll have all the pleasure of answering it.

Thank you, fixed.

Nice write-up! Btw. @Hibernate Validator supports the validation of monetary amounts and Currency out of the box; just add the Money JSR API:
https://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#section-builtin-constraints

Ref: https://twitter.com/gunnarmorling/status/1125709428945301504

Yes, that is an issue when we have a class with several fields.

I know that there are several frameworks whose can help us with this builder. Such as IntelliJ IDE with several plugins and templates. And these frameworks:

http://immutables.github.io/

https://projectlombok.org/

Hey, thank you. I glad that you liked it.

Yes, I could do a fluent API on the builder to make even more natural the constructor.

The point is the scope, and I would like to create both the builder pattern and a rich model to get data integrity.

There is an excellent article whose covers more this detail:

https://www.code-held.com/2019/04/29/robust-builder-pattern/

I avoided a final field because on the ORM frameworks such as Hibernate it uses reflections on the field; therefore, when you use this kind of tools usually don't use final fields, unfortunately.

Hey Robert, thank you for the comments.

Yes, you're right.

That still missing some points to make the model rich, that why I talked in conclusion about the next steps, otherwise, this post would be so huge.

Did you try the same test with the setter method? What was the result?

Hey, that is a Java EE project, so what we can do is run this command:

• mvn clean package tomee:exec -DskipTests

The source code: https://github.com/soujava/polyglot-persistence

Thank you, Denis.

Thank you, I'm delighted that you enjoyed it.