Refactoring

[michael-kamel]

There are couple of things that are slowly diverting from a proper path that probably need to be addressed now.

• Exceptions Currently the exceptions are thrown everywhere without any structure, It would be better if the exceptions are grouped and structured in a way that allows for their extension and usage(e.g. assigning error handling functions/codes)

• Tests Our tests are currently not coherent. As we have recently moved to in-memory db testing this should be easier to reason about. We need to

  1. Have a common package for all utils, mocks, stubs, spies, etc...
  2. Have a common standard (e.g. common lifecycle)
  3. populating the db with data for the test case is currently tedious and repetitive. this should be easily fixed if we do i & ii.
  4. Run the unit tests function wise

[dajenet]

The test part has yet to be done.

[chaoran-chen]

Please also take a closer look at all the tests involving the creation of an account or are sending emails. Especially sendContactRequest_prepare_mail_success() needs probably to be adapted.

[michael-kamel]

We might also resolve the passing of business domain entities in the controllers as part of this issue if there is time. One point I may add is we have to keep track of each change we make to an entity. For example, It could have been the case that we forgot to explicitly set the enabled attribute to false on the account when registering, causing anyone to be able to register an enabled account without email verification. The main idea is that this coupling will have us keeping a lot of stuff in mind and might get complex with time when making changes in general and to entities specifically.

[michael-kamel]

We should also restructure the file structure according to the layers we have. Structuring according to the entities is becoming hard to maintain properly.

[chaoran-chen]

Maybe this means that we should modularize the project better? Or do you prefer a horizontal structure in general?

[michael-kamel]

Not necessarily modularize but the point is the following, as the project gets bigger we will need additional services which are not entity specific and we will have some APIs which will require business logic that intersects 2 or more entities in general. The idea is, since we are following a layered architecture, it is probably best if we structure it as one in terms of how files are organized.

For example, we currently have logic regarding mailing, crypto, exceptions and so on. All of these are either scattered around in the entity services as sole functions or we have them as packages in the same level of the entities.

inter layer dependency is much more common so a horizontal structure will probably be much easier to maintain