Clean Architecture and contexts

[Jeroen De Dauw]

Two colleagues of mine and I have created an application that uses the Clean Architecture. HTTP requests to routes get turned into request models, which gets handed to use cases, which then spit out a response model that gets handed to a presenter.

The code is fully open source and can be found on GitHub [0]. We also have some docs describing what the main directories are about [1].

We are thinking about reorganizing our code and would like to get feedback on what we've come up with so far. Primarily amongst the reasons for this reorganization are:

* Right now we do not have a nice place to put things that are not part of our domain, yet somehow bind to it. For instance authorization code, which knows about donation ids. I've asked about this problem before on this list [2]. The answer by Łukasz Duda is part of the inspiration that went into our idea for reorganization. Thanks Łukasz!

* It's nice to group cohesive things together. Our Donation code is cohesive and our Membership Application code is cohesive, while both don't depend on each other. This is closely related to the notion of Bounded Contexts in Domain Driven Design. Right now these contexts are not explicitly visible in our code, so it is easy to make them dependent on each other, especially when you are not familiar with the domain.

These are the contexts we have identified so far. This is a preliminary list and just to give you an idea, and not the part I want feedback on.

* Donation
* Membership
* Form support stuff (validation of email, generation of IBAN, etc)

The part I want feedback on is the directory structure we think of switching to:

src/
    Context_1/
        DataAccess/
        Domain/
            Model/
            Repositories/
        UseCases/
        Validation/
        Presentation/
        Authorization/
    Context_2/
    Factories/
    Infrastructure/

tests/
    Context_1/
        Unit/
        Integration/
        EdgeToEdge/
        System/
        TestDoubles/
    Context_2/

The Authorization/ folder directly inside of the context would provide a home for our currently oddly placed authorization code in Infrastructure. Other code not part of our domain, yet binding to it, can go directly into the context folder, and gets its own folder if there is a cohesive/related bunch of stuff amongst it, such as authorization.

I'm happy to provide additional information you need to provide useful feedback.

[0] https://github.com/wmde/FundraisingFrontend/tree/master/src
[1] https://github.com/wmde/FundraisingFrontend/blob/master/README.md#internal-structure
[2] https://groups.google.com/forum/#!topic/clean-code-discussion/QTHOnpnQpOo