[WIP][POC] Refactor to tighten DDD setup and implement Hexagonal Architecture

[mvriel]

In order to make it easier to contribute to the project we need to make sure
that we make it as easy as possible. One of the ways to do this is to ensure
that we have an architecture that is well-understood and supported by
modern insights.

At current the DDD movement is gaining traction and with recent developments
has the hexagonal architecture style (or ports and adapters) become a main-
stream part of our community.

The advantage of adopting these is that they are pre-existing ideas and we
can stand on the shoulders of giants, like others.

This Pull Request is a PoC that we can use to discuss these concepts on; this may or may not be promoted to a full functionality set. I expect too many breakages in other PRs for this to happen but you never know :)

Tasks:

• Move Application-layer code to a sub-namespace Application
• Move Infrastructure-layer code to a sub-namespace Infrastructure
• Move DomainModel-layer code to a sub-namespace DomainModel
• Abstract Infrastructure concerns out of the DomainModel
• Add/refactor the command/handler for parsing the project to move all business logic away from the console commands
• Add/refactor the command/handler for rendering the project to move all business logic away from the console commands
• Consolidate the aggregates so that the file/folder structure matches the aggregates
• Move DomainEvents to root of DomainModel
• Move Commands to root of DomainModel

[jaapio]

I think we should move stash out of the domain model either. The DocumentationRepository depends on Stash now. But the middleware for caching is in the infrastructure layer.

[jaapio]

ConfigureCache command should be moved to the application layer, since it is using the configuration Factory.

Same applies to the MergeConfigurationWithCommandLineOptions

[jaapio]

RenderPass is still using flysystem directly. Shouldn't this be extracted to the infrastructure layer?

[mvriel]

I think we should move stash out of the domain model either. The DocumentationRepository depends on Stash now. But the middleware for caching is in the infrastructure layer.

Yes, the repository should be abstracted to an interface and the concrete class moved to Infrastructure or Application

[jaapio]

Dsn in the domain model feels more like a Application class for me. Or even infrastructure. Since it is all filesystem logic in there. Since it is only used in classes that we already marked as Application classes. It should be moved.

[mvriel]

RenderPass is still using flysystem directly. Shouldn't this be extracted to the infrastructure layer?

Well, RenderPass itself is a Domain Concept (though I am not really happy with this construct; we should revise it) but the Flysystem stuff should be abstracted away

[mvriel]

ConfigureCache command should be moved to the application layer, since it is using the configuration Factory.

Same applies to the MergeConfigurationWithCommandLineOptions

Done :)

[mvriel]

Well, RenderPass itself is a Domain Concept (though I am not really happy with this construct; we should revise it) but the Flysystem stuff should be abstracted away

I am going to do the revision of this part in a separate PR together with the Renderers; the RenderPass passes objects that should be abstracted away but I need a little headspace to shape that in the right architecture

[mvriel]

Dsn in the domain model feels more like a Application class for me. Or even infrastructure. Since it is all filesystem logic in there.

I am going to address this issue together with the Renderpass; it seems we can drop it