@geoffreyferrari.bsky.social
HATEOAS enables discovery at time of use. OpenAPI enables ahead-of-time discovery. It's an empirical question (to be answered by counting heads) how many prefer which approach, but my guess is that much more than half the world has decided that what they need is ahead-of-time discoverability.
February 13, 2026 at 8:13 AM
HATEOAS enables discovery at time of use. OpenAPI enables ahead-of-time discovery. It's an empirical question (to be answered by counting heads) how many prefer which approach, but my guess is that much more than half the world has decided that what they need is ahead-of-time discoverability.
I should maybe emphasize this even more. Large parts of domain logic are essentially implementations of functions in the mathematical/logical sense (mappings from one set of objects to another set of objects) and these are most naturally represented as Java maps, but hibernate often can't help.
September 14, 2025 at 8:40 PM
I should maybe emphasize this even more. Large parts of domain logic are essentially implementations of functions in the mathematical/logical sense (mappings from one set of objects to another set of objects) and these are most naturally represented as Java maps, but hibernate often can't help.
... so I have a `SecurityService` interface and an implementation of it which calls Spring Security context directly. It works very well, but I don't know anyone else doing it that way!
September 14, 2025 at 8:26 PM
... so I have a `SecurityService` interface and an implementation of it which calls Spring Security context directly. It works very well, but I don't know anyone else doing it that way!
I take authentication/authorisation logic to be part of the core domain logic, but that raises the question of how to connect one's core app with e.g. the API provides by spring security? My own answer is that spring security is an outside technology like any other...
September 14, 2025 at 8:24 PM
I take authentication/authorisation logic to be part of the core domain logic, but that raises the question of how to connect one's core app with e.g. the API provides by spring security? My own answer is that spring security is an outside technology like any other...
My two cents is that the underlying theory of HA leaves a lot of very important questions unanswered and there is not yet a community consensus on how to answer them. For example, if you use HA for a Spring REST API, is authorisation/authentication part of your core app or part of the adapter?
September 14, 2025 at 8:22 PM
My two cents is that the underlying theory of HA leaves a lot of very important questions unanswered and there is not yet a community consensus on how to answer them. For example, if you use HA for a Spring REST API, is authorisation/authentication part of your core app or part of the adapter?
But as I say, I'm also using jmolecules-hexagonal e.g. to mark ports with `@PrimaryPort` etc...
September 14, 2025 at 8:13 PM
But as I say, I'm also using jmolecules-hexagonal e.g. to mark ports with `@PrimaryPort` etc...
My projects are organised "vertically" with packages representing different features/modules. Within that, I do indeed have different packages for ports, use cases, domain classes. Something like:
[root]
package1/
application/
domain/
use-cases/
ports/
adapters/
[root]
package1/
application/
domain/
use-cases/
ports/
adapters/
September 14, 2025 at 8:12 PM
My projects are organised "vertically" with packages representing different features/modules. Within that, I do indeed have different packages for ports, use cases, domain classes. Something like:
[root]
package1/
application/
domain/
use-cases/
ports/
adapters/
[root]
package1/
application/
domain/
use-cases/
ports/
adapters/
I use a naming convention for ports (represented in code as interfaces) which basically describes what they do e.g. if I have a REST API for handling widgets, then I'd have a primary port named `GetWidget`. (Others may prefer `GetWidgetById`.) My adapters are then named e.g. `GetWidgetImpl`.
September 14, 2025 at 8:05 PM
I use a naming convention for ports (represented in code as interfaces) which basically describes what they do e.g. if I have a REST API for handling widgets, then I'd have a primary port named `GetWidget`. (Others may prefer `GetWidgetById`.) My adapters are then named e.g. `GetWidgetImpl`.
I already use jmolecules-hexagonal to help annotate my code...
September 14, 2025 at 7:59 PM
I already use jmolecules-hexagonal to help annotate my code...
How do I assign code to the ports and adapters? I implement ports as Java interfaces. Primary adapters call primary ports which are implemented as use cases. But there's an interesting asymmetry: Secondary ports are implemented by secondary adapters.
September 14, 2025 at 7:59 PM
How do I assign code to the ports and adapters? I implement ports as Java interfaces. Primary adapters call primary ports which are implemented as use cases. But there's an interesting asymmetry: Secondary ports are implemented by secondary adapters.
2) It allows looser coupling between my core application logic and external technologies. My core app connects to the outside world using an interface that it defines and which outside technologies must then implement. This allows me to change external technologies independently of my core app.
September 14, 2025 at 7:50 PM
2) It allows looser coupling between my core application logic and external technologies. My core app connects to the outside world using an interface that it defines and which outside technologies must then implement. This allows me to change external technologies independently of my core app.
I have two main reasons for using it:
1) Code logic and domain entities can be expressed using the best resources of the Java language and are not limited to what e.g. JPA/hibernate can provide. For example, I often want a map between non-basic entities, but hibernate can't do that.
1) Code logic and domain entities can be expressed using the best resources of the Java language and are not limited to what e.g. JPA/hibernate can provide. For example, I often want a map between non-basic entities, but hibernate can't do that.
September 14, 2025 at 7:47 PM
I have two main reasons for using it:
1) Code logic and domain entities can be expressed using the best resources of the Java language and are not limited to what e.g. JPA/hibernate can provide. For example, I often want a map between non-basic entities, but hibernate can't do that.
1) Code logic and domain entities can be expressed using the best resources of the Java language and are not limited to what e.g. JPA/hibernate can provide. For example, I often want a map between non-basic entities, but hibernate can't do that.
I think I'm A & C. I'm using Hexagonal Architecture so my domain classes are separate from my persistence classes. But both domain classes and persistence classes use application-generated UUIDs, except in very rare cases where there's a natural ID that I actually want to use.
July 11, 2025 at 9:12 PM
I think I'm A & C. I'm using Hexagonal Architecture so my domain classes are separate from my persistence classes. But both domain classes and persistence classes use application-generated UUIDs, except in very rare cases where there's a natural ID that I actually want to use.
No floccinaucinihilipilification from you in relation to this word then!
June 3, 2025 at 5:37 PM
No floccinaucinihilipilification from you in relation to this word then!
I guess you're serious, but... Moving to a new website url is just versioning by another name and doesn't seem to make life any easier for onself or 3rd party clients. So I guess HATEOAS is suppose to provide the magic sauce, but I can't even begin to fathom how it would help. Got an example?
April 14, 2025 at 7:31 PM
I guess you're serious, but... Moving to a new website url is just versioning by another name and doesn't seem to make life any easier for onself or 3rd party clients. So I guess HATEOAS is suppose to provide the magic sauce, but I can't even begin to fathom how it would help. Got an example?
Then the rule would be that adapters can only interact with ports and DTOs. I suspect that would be in line with the metaphor of electronics components that underlies ports & adapters architecture.
March 13, 2025 at 6:53 PM
Then the rule would be that adapters can only interact with ports and DTOs. I suspect that would be in line with the metaphor of electronics components that underlies ports & adapters architecture.
In some sense, it seems that I should be using DTOs rather than domain classes to send data to/from a database... But in practice, I'm not yet doing it that way.
Perhaps hexagonal architecture needs updating with the rule that ports can only use DTO classes, and it's fine for adaptors to use these.
Perhaps hexagonal architecture needs updating with the rule that ports can only use DTO classes, and it's fine for adaptors to use these.
March 13, 2025 at 6:52 PM
In some sense, it seems that I should be using DTOs rather than domain classes to send data to/from a database... But in practice, I'm not yet doing it that way.
Perhaps hexagonal architecture needs updating with the rule that ports can only use DTO classes, and it's fine for adaptors to use these.
Perhaps hexagonal architecture needs updating with the rule that ports can only use DTO classes, and it's fine for adaptors to use these.
FWIW, I've adopted the habit of only using DTO classes for primary ports. So, my primary adaptors don't depend directly on domain classes, only DTOs.
Would it be purer approach to hexagonal architecture to use the same rule for 2ndary ports? Maybe, though I haven't adopted that.
Would it be purer approach to hexagonal architecture to use the same rule for 2ndary ports? Maybe, though I haven't adopted that.
March 13, 2025 at 6:49 PM
FWIW, I've adopted the habit of only using DTO classes for primary ports. So, my primary adaptors don't depend directly on domain classes, only DTOs.
Would it be purer approach to hexagonal architecture to use the same rule for 2ndary ports? Maybe, though I haven't adopted that.
Would it be purer approach to hexagonal architecture to use the same rule for 2ndary ports? Maybe, though I haven't adopted that.
But I agree with you that ports and adapters arxhitecture raises conceptual issues which are not properly discussed anywhere (not anywhere I've found, anyway).
March 13, 2025 at 6:44 PM
But I agree with you that ports and adapters arxhitecture raises conceptual issues which are not properly discussed anywhere (not anywhere I've found, anyway).
Ultimately, I'm happy to let my adaptors use i.e. instantiate domain classes. My app has full control over how they are instantiated and how they are validated. Conceptually, I just think of them as part of the port specification, so it remains true that adaptors depends only on ports.
March 13, 2025 at 6:42 PM
Ultimately, I'm happy to let my adaptors use i.e. instantiate domain classes. My app has full control over how they are instantiated and how they are validated. Conceptually, I just think of them as part of the port specification, so it remains true that adaptors depends only on ports.
... it would be an astonishing coincidence if you could find exactly the external DTO classes you need! (Unless you specifically wrote them yourself).
March 13, 2025 at 6:40 PM
... it would be an astonishing coincidence if you could find exactly the external DTO classes you need! (Unless you specifically wrote them yourself).
If the question is "Are adapters allowed to reference domain types" then my answer is that it's not merely permitted but effectively required. The types referenced in a hexagonal app's ports are either defined inside your application or you use some kind of externally defined DTO classes. But...
March 13, 2025 at 6:38 PM
If the question is "Are adapters allowed to reference domain types" then my answer is that it's not merely permitted but effectively required. The types referenced in a hexagonal app's ports are either defined inside your application or you use some kind of externally defined DTO classes. But...