Why do some contexts contain port & adapter modules and others don't?

[Midnighter]

I have a doubt about the code organization. As an example, the com.saasovation.identityaccess.infrastructure.persistence package contains classes that implement repositories using hibernate. But a similar purpose is served by the com.saasovation.agilepm.port.adapter.persistence package in the other context which was implemented with LevelDB.

One possible explanation that I see is that hibernate is considered the adapter and that's why there is no need for implementing a package com.saasovation.identityaccess.port.adapter.persistence. However, in the agilepm context, there is no infrastructure layer at all and only the port & adapter layer. Is that because, for example, com.saasovation.agilepm.port.adapter.persistence.LevelDBSprintRepository fulfills the role of infrastructure and adapter at the same time and you chose to to not separate those concerns?

Another doubt is that the endpoints declared in the com.saasovation.identityaccess.resource package are at the "top level" of that context. I would have expected them to be in port & adapters.

Thank you for any help to clear up my confusion.

[Deviad]

We are two, I have the same doubt.
I asked ChatGPT, but he seems confused as well.

[VaughnVernon]

@Midnighter @Deviad I just saw these comments.

There's a simple explanation, and one possibly covered in my red book from which these examples are taken 📕 (It's been a long time since writing.)

There are three different teams (simulated). They all use Ports and Adapters (Hexagonal) architecture, but employ different naming for the same kind of Modules. Different people think differently, and that's okay. 😃

There is a second reason, too. As a teaching approach, it also demonstrates different ways to communicate that part of the architecture. The book and code examples are meant to teach, not to impose my personal taste on readers so as to make them more likely to conform. 📕 👨‍💻

And you've already noted that (IIRC) one of the three teams uses a different database product (LevelDb vs MySQL).

I'm pretty sure that most don't realize how much careful thought goes into writing, at least so for me. I don't know whether the C# .NET examples take the same approach as those are human translations from Java.

And BTW, I have used both of these naming conversations elsewhere. I do hate the long name "infrastructure" so if I actually use that naming I generally shorten it to "infra". Although that's an abbreviation, it's not an ambiguous one.

[Deviad]

Thank you @VaughnVernon for taking the time to answer, really appreciated. At least now if someone in an interview, or a work colleague, is in the mood to have a debate about one of these nuances, I can tell him to come here and read your comment. :) Wish you a nice weekend.  Kind regards, Davide