Hom(OrderService, InventoryService) = {
checkAvailability: Order → Availability,
reserveItems: Order → Reservation,
releaseReservation: ReservationId → Unit,
decrementStock: Order → Unit
}
In the first case all the morphisms in the hom-set should have the same type, and the second doesn't make sense semantically.
Hence it should be the hom-bifunctor considering both as categories, but then we should get natural tranformations in the answer.
I assume there's some notational abuse going on that I'm not picking up on. Either way it would be nice if someone more adept could clarify.
znort_•2mo ago
if you're building real systems you should focus on both.
> Coupling as Hom-Set Size ... The second interface is easier to implement, test, mock, and evolve.
i would doubt that. this just hides the complexity of multiple interfaces inside single, more general interfaces. if those "arrows" actually exist you will have to test and evolve them anyway, and adding some extra classification level does little apart from adding complexity.
> Pipelines ... Why This Matters ... Testability: Each morphism can be tested independently
i agree ... and this just contradicts the previous point about hom-set size.
> The arrows are what matter.
everything matters. i'm aware of the benefits and appeal of category theory, but i don't see the need to shoehorn it into everything, this just seems an example of evangelization of extremes. iow: if your only tool is a hammer everything looks like a nail, and that's not conducing to good design.
karmakaze•2mo ago
This is an XY problem statement. We need Y to do X (the following):
> “We need these operations on user data: create, read, update, delete, authenticate, authorize”
znort_•2mo ago
no, it isn't. we need both, they're different aspects of the same thing. hyperfocusing on the former and disregarding the latter is just as bad as doing the inverse, and is exactly the problem i was describing.