Add Fraud Detection example

[SullivanDaly]

What is the goal of this PR?

Adding a fraud example using quarkus in order to get a graphql front end.

What are the changes implemented in this PR?

This project uses Quarkus, the Supersonic Subatomic Java Framework in order to let us present results with GraphQL. In this project, we use TypeDB to represent a queryable database of relevant fraud detection data about some transactions between Cardholders and Companies.

We can also see how easy it is to create complex queries using query composition.

We are using the DAO design pattern on which our design depends to be able to treat data and demonstrate query composition in TypeDB.

[typedb-bot]

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

---

Trivial Change

• [ ] This change is trivial and does not require a code or architecture review.

Code

• [x] Packages, classes, and methods have a single domain of responsibility.
• [x] Packages, classes, and methods are grouped into cohesive and consistent domain model.
• [x] The code is canonical and the minimum required to achieve the goal.
• [x] Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• [x] Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• [x] The code is algorithmically efficient and scalable for the whole application.

Architecture

• [x] Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• [x] Any required build and release automations are updated and/or implemented.
• [x] Any new components follows a consistent style with respect to the pre-existing codebase.
• [x] The architecture intuitively reflects the application domain, and is easy to understand.
• [x] The architecture has a well-defined hierarchy of encapsulated components.
• [x] The architecture is extensible and scalable.

[jamesreprise]

@SullivanDaly @shane-k-j See the above comments. Sometimes GitHub comments will say 'outdated', but the content is still relevant if I have not resolved it. Once we address all of the unresolved comments, I'll have a go running the example and then we should be ready to merge!

[alexjpwalker]

@SullivanDaly cc @jamesreprise When submitting PRs, also ensure that the PR title and description are refined: see https://forum.vaticle.com/t/code-contributions/176#vigilant-mode-5 for the guidelines!

---

The current PR template is:

For the title of this PR: please follow the grammatical rules of a usual publication title, without capitalisation (except for the first letter). Thus, the title should NOT CONTAIN CODE: no dots, no parentheses, no backticks, no brackets, etc. It needs to be distinctive (not detailed) and succinct (not lengthy). Details of this PR will go in the description. For the description of this PR: please replace every line in curly brackets ( { like this } ) with an appropriate description following the guidance. Finally, please remove this paragraph.

What is the goal of this PR?

{ In the form of a paragraph (only use bullet points if strictly necessary), please describe the goal of this PR, why they are valuable to achieve, and reference the related GitHub issues. This section will be automatically compiled into the release notes, so please:

• describe the impact of the change in this PR to the user of this repository (e.g. end user, contributor, developer).
• describe the new product behaviour in present tense, and the old behaviour and how it's been changed in past tense.
• Use the Royal We: "We" made changes, not "I" made changes. }

What are the changes implemented in this PR?

{ Please explain what you implemented, why your changes are the best way to achieve the goal(s) above. Please describe every method, class and package, by explaining:

• its responsibility,
• how it's expected to behave, and
• how it relates to the adjacent methods/classes/packages it interacts with.

This would allow the reviewer to understand your intentions in the code much better. If you're adding new classes, make sure these explanations are also included in the class header comments. Last but not least, please reference the GitHub issues to be automatically closed, such like 'closes #number'. }

---

Feel free to browse previous (recent) PRs in this repository to get a general feel for how we present PRs.