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-

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.


-- Matthieu Baechler

To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Reply via email to