Hi there, I think that my thoughts about components seem to be quite aligned with those of Eugen, so I won’t really repeat anything here. I agree with pretty much everything he writes about the advantages of having clean components. Perhaps the only thing I would point out is that even with clean APIs, you can still “mix up” the implementations. There is nothing prohibiting using a single “super protocol implement” that implements all of the protocols, even if the APIs are very cleanly separated.
I will only repeat that to have good componentization, independent (i.e. non-coupled) and very clear APIs are a necessary prerequisite. So to really get the most of Guice, I think there is some work to be done. Regarding the hexagonal architecture, I am not quite sure what to say. It sounds good on paper, but IMO any good architecture should help with communication. For the life of me I can’t seem to find my way around even knowing that it is based on this architecture. I don’t find any hints in the code. Can you direct me? However…. Maybe given the current state of James we could just take a completely different approach. Instead of aiming for clean componentization, which would be a huge undertaking, and in any case the specs seem very “dirty” to me, and since James is already “working” maybe we could just use the “black box” approach. It is a closed system, so it doesn’t need APIs for its components. The “interface” is simply a clean input and output function for emails. Come to think of it, maybe that’s what the hexagonal architecture ends up doing?? Cheers, =David
signature.asc
Description: Message signed with OpenPGP
