Epic: Structure for quarkus showcase(s)

[hohwille]

So far we have created a first sample app as reference for quarkus.
Next we need to added and demonstrate how services will communicate with each other.
This will grow over time.
A first aspect is to demonstrate technical features: openTelemtry, Istio, Kafka, etc.
Another aspect is the business logic behind this.
Ideally the things should fit together and make sense. So we could create a service using Kafka but if the use-case to demonstrate it does not match to eventing then there is no much use in it as a reference.
As our initial service is managing animals, we could continue and create a zoo as the next service.
However, my fear is that we end up with a lot of nonsense this way. From my-thai-star (MTS) we have already learned a lot how sample apps can eat maintenance effort and cause headaches...

I see two general options:

1. we step by step create quarkus services that in the end shape a new MTS
2. we use a more simple but still meaningful example domain what is e-commerce: We refactor our sample app to maintain products that have a price. Then we can create a second service for ordering. If we want to grow further, we can create a billing service, fulfillment & shipping, etc.

Benefit of 1. is that we could reuse specification, design and UX efforts and streamline with our exsiting MTS.
However, the drawback is that we create yet another "monster".

Therefore, I actually prefer to go for 2. as it simple and does not foster to grow large (like a full grown restaurant with reservation, etc.). Also if we go into such direction we should also name the services accordingly to business. In the documentation we can say "the reference for providing a REST service can be found in devon4quarkus-product service here" and in another place "the reference for consuming a REST service from a quarkus backend can be found in devon4quarkus-order service here".
That is we do not have "devon4quarkus-reference" and later a "devon4quarkus-rest-client-showcase" or a "devon4quarkus-kafka" repo but use logical naming and keep the technical labelling in READMEs and by linking from the right places.