Clean Architecture's class diagram, is this how you see it too?

[Breno Sarkis]

So I decided to draw a diagram. Like a class diagram if you will. I decided to include some methods in case the arrows and names confuses you.

Hopefully you'll point out things I've missed or misunderstood. I wanna hear from you, what you think of it, please, feel free to critize, this is what I'm looking for!

Please consider:

- The I prefix in the interfaces are to easy .net developer's understanding, not necessarly how the code will look like.

- When my UI is based on the ASP.NET framework I do not segregate the presenters and controllers, I use them in the same place, seperated by folders only.

- I decided not to segregate the resquestors / responders, instead I got all 4 interfaces in the same component ( though this may be bad ? )

- Though I'm using interfaces for the request/response abstraction it could be an abstract class or degenerate type (which I haven't been able to understand completely)

Here it is:

One thing I'm considering (to easy the creation process, though I might be missing something) is to remove the Request/Response interfaces, then I'd move the concrete Data Structures to the boundary project and have the Interactor implementation comunicate to them through the boundary. Would this couple my UI to my use cases too much?

[Sebastian Gozin]

I feel like there is something strange going on with the IPresentCarResponse.
There are 2 of them?

I thought .NET did not allow "has a" associations starting from an interface but I won't press that technicality.
But it is confusing me a bit on exactly how the PresentCarPresenter and PresentCarResponse instances used by CarController and PresentCarInteractor respectively can possibly be the same instance.
I don't see any way they are exchanged.

Also based on this diagram I would think the interactor would simply update the PlateNumber field at some point.
How does CarController know this happened? Is Execute blocking?

Otherwise I'd say this is very similar to how I tried it the first time around. I'll refrain from saying that is the correct way but it is encouraging to see I'm not the only one.
Finally, I've found myself to use generic components where "car" would be part of the request so I did not have to build the same kind of structure over and over for every possible concept I might want to support.

[Breno Sarkis]

Hi Sebastian,

Yeah, there are... kinda. If you watch episode 18, you'll see that UB uses "degenerate" type to isolate the Interactor response object, and the one the UI knows about, same thing to the request object. In my example I decided to use an interface (and to be honest, I don't even know why, I don't think I understand the purpose of a degenerate type, therefore I wouldn't be able to explain it to my team).

What happens is, controller creates the concrete presenter, and asks for a new interactor (all this is done by a IOC container in a different project, so the ui doesn't know about the concrete interactor, only the boundary), inside the interactor's execute method I create the concrete response object, and passes it to the presenter object, so it can present it.

Hmm... I gave those classes fields to show that they're only data structures, so it is just an example really, but my intent was to show that, your request lets you decide whether you want to display broken cars, and by having the plate number on the response, means you can only see the plate number of a given car.

In an ASP.NET MVC project, everything goes through a controller, thats why I did not separate it from the presenter, because the controller is always the starting point.

This is a challenge I'm yet to face, I know I cannot pass the entity upwards, it must not cross the boundary layer, so I know I can't have it "be the request" or "be the response". I must create response and request objects from it if necessary, and this bothers me a little bit. As an example, imagine I'd be listing cars, so my response is really a list of cars, what would the presenter expect? a List<ResponseObject>? or a ResponseObject with a List<Car> inside it? I prefer the second case, and to make that work and less ugly, I create a new Car class as a nested class of the response object. So I can Achieve ResponseObject.Cars.

Another way to solve this would be to change the response object's name to "PresentableCars" so it makes sense to have a List<PresentableCar> rather than a List<ResponseObject>. Have I lost you here?

[Breno Sarkis]

Actually, Sebastian pointed it out correctly, there is a typo in the image, I ended up naming the PresenterInterface as IPresentCarResponse! fixed version is below:

[Edno Silva]

Breno, there is a class that was renamed to ListarCarroResposta. It should be named in English, right?

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
To post to this group, send email to clean-code...@googlegroups.com.
Visit this group at http://groups.google.com/group/clean-code-discussion.

--

Sem mais,
Edno.

[Breno Sarkis]

Edno, Definetely! my bad, once again :)

I have to keep two versions of this, since we have to write code in portuguese. The only reason the english version exist is to communicate with the folks here.

updated version:

Thanks Edno, although I'm not getting as much response as I thought I would, Im very glad to know people are looking at it at least :)

[Sebastian Gozin]

In Portugese oh my...
Reminds me when they wanted me to write stuff in Dutch.

It needs to be in the language of the domain they said.
I don't think they understood what language means.

Or maybe I don't.
I think language of the domain means concepts from the domain but not necessarily a specific spoken language.
So it turns out in a country where people speak either Dutch, French, German or English then choosing one other than English significantly reduces who you can hire.

[Breno Sarkis]

Sebastian, It is good you've brought this up.

This is a challenge I've been facing for quite a while now. All the patterns, the programming language itself and almost every concept is defined in english. Take the world "Presenter", it has a clear translation to portuguese, but "Interactor" doesn't. What should I do? 

I know that the software I'm about to write belongs to my client, and they do not want my team to write anything in english, they're the owners they're the ones who'll maintain the code when we're gone.

IMO portuguese is a weird language and doesn't fit very well in the art of programming. There are so many ways to describe the same thing that it is difficult to create and maintain naming patterns. No other word to define this other than Struggle.

I believe I've lost this war.