Hi David, On Sun, 2020-05-17 at 15:01 +0900, David Leangen wrote: > Hi! > > [...]
> Organizing into Guice Modules is very nice. One of the important > benefits is that it helps a lot to break the system down into > reasonable chunks that are more understandable. It is simply > impossible for a normal human to understand the system all at once. > It is necessary to have several levels of abstraction. The use of > Guice Modules to provide a “just right" level of abstraction (not too > high so as to be useless when trying to run it, but not so low as to > be much too detailed) is essential. I would wager that in most > situations, this is the level of abstraction that is most useful for > a developer or system operator (and definitely for an application > assembler). The only time a package or class level is necessary is > when actually making changes to the code. Let me disagree. Guice is a technology we use but it is not mandatory, we could change this part of James tomorrow if we want, it's an implementation concern. What makes James special is the hexagonal(-ish) architecture it uses. I won't go into details here about why it's not exactly how it should be but to understand James you have to understand this design. Basically, you have: * `domain cores` (say managing emails and mailboxes, managing users) that implement the important domain logic * `ports` that define some APIs required for `domain cores` (mailbox- api is a port) * `adapters` that provides the implementation of a `port` (mailbox- cassandra) When we define a `port` API we provide a contract testsuite to check that the implementations will work well plugged-in. So to come back to the analysis: the right level of abstraction for James architecture is these three entities. Unfortunately, there's not way to visualize the hexagons from the code right now. Finally, I see Guice module documentation as a problem: we usually document things that are supposed to last. Documentation reduces the ability to refactor things. As Guice modules are technical classes, I would not like to be refrained from refactorings because of this documentation. It's why I think we have to find a way to document `ports` and `adapters` because they are definitely more stable. Cheers, -- Matthieu Baechler --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
