My category theory is pretty rusty, but I'm not following the section on hom-sets. In particular:
Hom(OrderService, InventoryService) = {
checkAvailability: Order → Availability,
reserveItems: Order → Reservation,
releaseReservation: ReservationId → Unit,
decrementStock: Order → Unit
}
doesn't make sense to me as a hom-set between objects in our category of services, nor as a hom-functor considering one of {OrderService,InventoryService} to be a category and the other and object or morphism within the category.
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.
> They focus on objects when we should focus on morphisms.
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.
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.
My category theory is pretty rusty, but I'm not following the section on hom-sets. In particular:
doesn't make sense to me as a hom-set between objects in our category of services, nor as a hom-functor considering one of {OrderService,InventoryService} to be a category and the other and object or morphism within the category.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.
> They focus on objects when we should focus on morphisms.
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.
> “We need a User Service”
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”
> This is an XY problem statement
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.