We Keep Coding

Why is composition labelled as a subset of aggregation in some illustrations?

Referring to an Image I found online. It labels Composition as a subset of Aggregation.
As per my understanding Composition is a form of tight coupling like when we instantiate an object inside another object. While Aggregation is a form of loose coupling kind of like a Dependancy Injection. They both seem different so why would Composition be a subset of Aggregation?
Image:
https://algodaily.com/lessons/association-aggregation-composition-casting

Because it's historical state of the art an not true for UML 2.5. Aggregation as attribute of a Property is explained on p. 110 of UML 2.5:
none | Indicates that the Property has no aggregation semantics.
shared | Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
composite | Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (see the definition of parts in 11.2.3).
So actually both stand side-by-side with shared having no semantics whatsoever. Former UML specs had some definition which made shared some kind of subset. But that is just history. Though, you don't get it out of people's heads.

Composition is a specialized form of aggregation. In composition, if the parent object is destroyed, then the child objects also cease to exist. Composition is actually a strong type of aggregation and is sometimes referred to as a “death” relationship.

What is the difference between "Persistent Class" and "Entity" in JPA or in Hibernate?

First things first:
I'm aware of this question, which, at the high level of abstraction, asks same what I ask here; however, I find it (and its answer) lacking, therefore, I would like to elaborate on this topic here;
I would kindly ask anyone, who has a good understanding of the formal definitions in the JPA and Hibernate, to help me clarify this mess.
Disclaimer: I am not looking for the basic explanations of what the Entity is and how to use it. I am using Hibernate/JPA for quite some time now.
My question is more about formal definitions, in order to clarify the distinctions of the formal semantics (definitions) between Entity and Persistent Class, to make it crystal-clear how one differs from another and how they are defined.
Initially, I expected the answer to be found in JSR 338: JPA Specification 2.2 and Hibernate 5.0.0 Reference Documentation, but I got quite confused, as I was left with a feeling, that, in this context, both documents are lacking, leaving a big room for these concepts/definitions to overlap and introduce some speculations.
Let's start with JSR 338: JPA 2.2 Specification:
For some (very strange to me) reason, in this entire specification, keyword phrases "Persistent Object" and "Persistent Class" are not found, to wit, they are found only once and twice respectively:
Persistent Object - found in the Javadoc comment, saying nothing interesting (page 221)
Persistent Class - found in the xsd documentation, again, saying nothing much (pages: 378, 529)
and, unfortunately, that is it in this specification, nothing more at all.
The Entity Class, on the other hand, is defined as follows:
An entity is a lightweight persistent domain object. The primary programming artifact is the entity class. An entity class may make use of auxiliary classes
that serve as helper classes or that are used to represent the state of the entity.
which, again, I find extremely lacking for the formal specification document, but at least, this says that it is a persistent domain object.
In the same document, Entity is also defined as a Class (2.1 The Entity Class, page 23).
Even though this might not seem important, it's quite confusing whether it's defined as a Persistent Object or as a Class.
My conclusion based on this specification document:
Persistent Class/Object is not defined in the JPA 2.2 Specification at all;
Entity is defined as persistent object, and(!), as a Class, which is really unclear to me;
In my conceptual understanding, Persistent Object, sounds very much as an object, which is persistable if(!) it will be mapped correspondingly; hence, Persistent Class - as a Class, instances of which are possible to get persisted (i.e. they can be stored into database layer, by conforming to POJO concept), if the class is mapped accordingly. I.e. Persistent Class is a persistable class, and it transforms to Entity, if it has its corresponding mapping definition (either with .hbm.xml or JPA annotations).
Hibernate 5 Reference Documentation
On the other hand, Hibernate defines Persistent Classes, and it does this as follows:
Persistent classes are classes in an application that implement the entities of the business problem (e.g. Customer and Order in an E-commerce application). The term "persistent" here means that the classes are able to be persisted, not that they are in the persistent state.
Am I getting this correct, that Persistent Classes implement the entity means, that my upper understanding is correct, and Persistent Class is just a Java class, which implements the Entity model (without mapping), and in conjunction with its mapping (.hbm.xml or JPA) it becomes an Entity? is Persistent Class + Mapping Definition = Entity correct?
I would also plug here in some snippets from the Java Persistence with Hibernate, Second Edition book:
You wrote a persistent class and its mapping with annotations. - (Summary 2.4);
kind of, differentiates persistent class from its mapping, and that, again, sort of supports the idea, that persistent class and its mapping are distinct concepts, which logically brings the point, that persistent class alone, is not an Entity.
The persistent classes are unaware of—and have no dependency on—the persistence mechanism. - (Chapter 3.2);
clearly states, that Persistent Classes are unaware of the persistence mechanism.
You can reuse persistent classes outside the context of persistence, in unit tests or in the presentation layer, for example. You can create instances in any runtime environment with the regular Java new operator, preserving testability and reusability. - (Chapter 3.2).
also supports the idea, that Persistent Class is not necessarily a mapped Entity.
My conclusion:(based on my initial understanding, which seems to be supported by "Hibernate Reference Documentation" and "Java Persistence with Hibernate, Second Edition" book.)
Persistent Classes are Java classes, which (if needed!) would be conforming with the JPA Specification (according to which, they need to be POJOs and they can be mapped), but they are not Entities if they are not mapped, and they can be used in the outside-of-JPA context, to just operate on them as on ordinary Java objects, or even to present them at the Presentation Layer.
Finally:
As you can see, my question is a bit of a mixture of different resources, showing my evident confusion, as I cannot clearly define the formal, so called scientifically adopted definitions for these two concepts.
Can we clearly define what is the Persistent Class, what is Entity, and what is the the semantic and definitive difference/overlapping between them in terms of JPA and Hibernate?

Class, Object, Entity: What's the difference?

I also see other terms as well: Entity Object, Value Object, etc. Are there other terms out there that I should know, and what do these terms refer to?
Can the differences between them, if any, be identified by reading code?

A class is a template for creating objects. Not all OO languages use classes (see Self, Javascript). Typically classes are implemented as objects.
An object is a bundle of data that is packaged with functions that act on that data (called methods). Calling a class's constructor allocates memory for the object and initializes its member variables.
An entity is an object that represents something that has an identity that the system is interested in tracking. Typical examples are Customers and Accounts.
A value object is a value, it doesn't have an identity, and two instances with the same value are considered to be identical. Typical examples are monetary amounts, locations, payment types.
A data transfer object is used for passing a bunch of data around. Typically they're used in distributed systems to send data as a bundle in order to avoid repeated network calls. Data transfer objects have no identity (or there is no expectation they should have any), they are just containers for data.
Generally you can tell the difference between entities and value objects because entities have a recognizable identity, and the system is concerned with creating them, storing them, and changing them. In cases where objects map to some database, entities have primary keys that are either some kind of composite natural key or an artificial key, while value objects are compared by value.

In general a class is a construct which defines a set of properties and methods/functions while an Object is the actual instance of a class which is created at runtime.
Sample class definition:
public class Example{
...
}
The following will create an instance of the Example class as an Object at runtime;
new Example();

Class defines an entity, while an object is the actualentity
Class is a conceptual modelthat defines allthecharacteristics and actions required of an object, whilean object is a real model
Class is a prototype of an object
All objects belonging to the same class have the samecharacteristics and actions

Aggregate object in DDD

I have made an aggregate class named Question. This contains references to Answer, Category, Feedback objects. Should the QuestionRepository be the class that contains all methods quering the database that relates to the Question but also all the methods for quering the Feedback, Answer etc? Or should these be seperate classes such as QuestionRepository, FeedbackRepository and so on.

From the way you have explained , I am assuming that each Question will have 1 or more Answers , 1 or more Feedback and the Question belongs to a particular Category
Since the Answer and Feedback are dependent on Question and cannot exist independently , you can have a single QuestionRepository for these 3 entities .
Coming to Category , category is more of a static entity which IMO is a static list , so all such static entities can be grouped together in a StaticRepository

From the DDD web site :
For each type of object that needs global access, create an object
that can provide the illusion of an in-memory collection of all
objects of that type.
A repository is used when you need direct access to an entity, i.e. when there's no other convenient way to get hold of that entity than fetching it from a persistent store directly. In contrast, if you consider that the entity is most of the time easily obtainable through traversal of another object you've already got at hand, then there's no need for a repository. It seems to be the case with Answer, Category, and Feedback here.
Usually repositories are only for aggregate roots, though there may be exceptions.
I suggest you read the DDD blue book or some tutorial to get a basic comprehension of the DDD building blocks before you start building your domain model.

Is a Data Transfer Object the same as a Value Object?

Is a Data Transfer Object the same as a Value Object or are they different? If they are different then where should we use a DTO and where should we use a VO?
The programming language we are talking about is Java and the context is - there is a web application, which fetches data from a database and then processes it and ultimately the processed information is displayed on the front-end.

A value object is a simple object whose equality isn't based on identity.
A data transfer object is an object used to transfer data between software application subsystems, usually between business layers and UI. It is focused just on plain data, so it doesn't have any behaviour.

A Data Transfer Object is a kludge for moving a bunch of data from one layer or tier to another, the goal is to minimize the number of calls back and forth by packing a bunch of stuff into the same data structure and sending it together. Some people also use it, like Michael points out in his post here, so that the classes used by one layer are not exposed to the layer calling it. When I refer to DTO as a kludge, I mean there's not a precise abstract concept getting implemented, it's a practical workaround for helping with communication between application layers.
A Value Object is something where we're only interested in its value, like a monetary amount, a date range, or a code from a lookup table. It does not have an identity, meaning you would not be concerned, if you had several of them, of keeping track of which is which, because they are not things in themselves.
Contrast Value Objects to things that do have a unique identity in your system, which are called Entities. If you have a system where it tracks a customer making a payment, the customer and the payment are entities, because they represent specific things, but the monetary amount on the payment is just a value, it doesn't have an existence by itself, as far as your system is concerned. How something relates to your system determines if it is a Value Object or an Entity.

use a DTO at the boundary of your services if you don't want to send the actual domain object to the service's clients - this helps reduce dependencies between the client and service.
values objects are simply objects whose equality isn't based on identity e.g. java.lang.Integer
DTOs and value objects aren't really alternatives to each other.

They are different, but I've even used the two interchangeably in the past, which is wrong. I read that DTO (Data Transfer Object) was called a VO ( Value Object) in the first edition of the Core J2EE Patterns book, but wasn't able to find that reference.
A DTO, which I've sometimes called a Dumb Transfer Object to help me remember it's a container and shouldn't have any business logic is used to transport data between layers and tiers. It just should be an object with attributes that has getters/setters.
A VO however is similar to a JAVA Enum and represents a fixed set of data. A VO doesn't have object identity (the address of the object instance in memory), it is identified by its value and is immutable.

Martin Fowler, talking about Data Transfer Objects (DTOs):
Many people in the Sun community use the term "Value Object" for this pattern. I use it to mean something else.
So the term "Value Object" has been used to mean DTO, but as of him (and the other posters), its use as a DTO seems discouraged.

Good detailed answer in Matthias Noback article Is it a DTO or a Value Object?
In short a DTO:
Declares and enforces a schema for data: names and types
Offers no guarantees about correctness of values
A value object:
Wraps one or more values or value objects
Provides evidence of the correctness of these values

Maybe because of lack of experience, but I would put it this way: It's the matter of scope.
DTO has word transfer in it so it means some parts of the system will communicate using it.
Value object has smaller scope, you will pass set of data in value object instead in array from one service to the other.
As much as I understood niether of them is "object whose equality isn't based on identity".