Clean archi standards

[trmalek]

Hello,
first of all thank you on the effort and all your linkedin posts. That's very interesting.
Allow me to send you a few remarks on the banking kata code (for information, I am not from the java world, so some remarks may not be valid):

• I notice a lot of annotations in the domain (lambok) why? isn't that overkill in your kata? And I saw that: lambok.experimental is an experimental lib?
• For the exceptions part I see that we have a repositoryException. It is technical word in domain and it is worth nothing we must explain the exceptions by model domain and be close to the business lexicon (ubiquitous language). For example, we can have an accountException class and methods inside that express the different exceptions related to Account and so on...
• I don't see the notion of Presenter, it's true that it's a simple case, what do you think?

Best regards.

[valentinajemuovic]

Thanks @trmalek!

1. Regarding the requests and responses, there are three approaches:

1.a) The plain vanilla Java approach would be private variables firstName, and lastName, and then hand-writing get firstMame, setFirstName methods. One could consider this the "purest" approach, since no dependency on any library, i.e. plain Java.
1.b) The lombok equivalent is that I write the private variables firstName, lastName, etc. but then use the lombok annotation to avoid handwriting the annotations.
1.c) Lastly, another vanilla Java approach would be to have PUBLIC variables, which can be directly accessed, with no getters/setters

Regarding these three approaches, there isn't yet a globally accepted consensus which way one should go, so I see them all as valid, though this is a great topic, because a team should think about which way to go.

Regarding the lombok experimental, yes, the reason is due to the @UtilityClass - it's for classes which only static methods, so I avoid writing a private constructor. Again could have been done with plain Java. In other languages (like C#), this isn't necessary since C# already has a static keyword for classes...

2. Exceptions - yes, you're right, they should be in terms of the domain. This is an improvement point which I'll be tackling in subsequent refactorings.

3. Notion of the presenter - another great topic. There are two approaches:

3.a In Uncle Bob's original Clean Architecture page https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html he writes about the Presenter, and the flow with Use Case Input Port, Use Case Interactor, Use Case Output port. This kind of approach is illustrated by @ivanpaulovich here https://github.com/ivanpaulovich/clean-architecture-manga/tree/main/accounts-api/src/Application/UseCases/Deposit

3.b. Another approach is without the presenter, but instead use case handlers WITHOUT presenters, which Uncle Bob takes here (this was done several years after his blog post above) https://github.com/sandromancuso/cleancoders_openchat/blob/openchat-unclebob/src/main/java/org/openchat/usecases/GetSubscribedDocuments.java and that approach is also visible in Ian Cooper's clean architecture example, i.e. request/response and use case handler. Both of these approaches are without presenters.

I thought about this during the past few years, I currently prefer 3.b. Furthermore, in 3.b. one may pass in separate args into the use case, e.g. no Request object, but rather separate args, or having a Request object which holds multiple variables. I prefer it withRequest objects. Overall, this is a good topic, I want to document these different approaches and pros and cons.

[marciovmartins]

3b. In this example, if the rest api (controller) can return an pdf document or an json, wouldn´t be responsibility of the controller to translate that in the correct format?

The use case would return a DTO and the controller would be responsible to map to the correct presentation. What would be the usage for a Presenter?

I'll read the link that @valentinacupac posted here. Thank you

[marciovmartins]

Or those Presenter would be the old mapper in the Controller layer?

[marciovmartins]

Could you give me some example? The use case is an orchestrator, in this situation I see that some kind of flag or type would need to be passed to the use case so they could provide the right presenter. Is it like that?

[trmalek]

You must make the difference between the presenter in the use case which provides the viewmodel exploited by the controller and the view which the controller must provide using view model. Thank you for the link @valentinacupac I already saw, it is very interesting...

[trmalek]

@marciovmartins
for example if we have a lot of logic to build the view model or as you call it DTO returned by the use case. It is not at the use case that will manage the data formats to be sent to the controller or the transformation logic etc. A small example fullname built by two data first and last names it is not the role of use case rather the role of presenter to build this (we agree that DTO does not contain logic, it just transfers the data). And in the controller you have another presentation (the view) for example this viewmodel which contains the well-formatted data we will present it in a csv or pdf file etc. That's in the controller: use the response of your framework or we can create a small service which will take care of this presentation on the controller side if it is very complex for example generate few pdf pages using viewmodel provided by the presenter (interface) injected in use case) In any case, it depends on the context ...