1. Passing from Domain to Data

This is correct, Data receives an object from Domain and maps it to whatever Entity the data implementation expects.

1. Passing from Presentation to Domain

If I am reading it correctly, UserModule is the Dagger Injection Module for the User scope, so you should not hold instances of other classes in that UserModule. It exists purely to provide instances to inject.

You are not obliged to keep to the protected Observable buildUseCaseObservable() format, since this makes it hard to use when you have dynamic objects that need to be passed to a UseCase. What i would do is have a method which takes a User from the Presentation Layer and have a UserMapper declared in the Presentation Layer which would transform the UserModel to a User and pass that on to the Domain Layer.

So the flow would be

Presentation layer

• user fills in some fields and clicks OK
• the presenter gathers the data and constructs a UserModel
• the UserModel is passed to a mapper to convert it to a User
• SignUpUseCase.signUp(user) is called

Domain layer

• SignUpUseCase receives the User
• ( here you could apply more business rules first)
• the UseCase transforms UserModel to User and passes it to your Service

Data layer

• UserService receives the User
• User is used to sign up in the cloud via the Service
• On response, the SignUpUseCase is notified

Domain layer

• SignUpUseCase processes the result and applies any business logic (let's assume the signup was a success)
• our implementation requires us to save the User locally, so we pass it to the UserRepository
• probably after this, we notify the presenter of the result

Data layer

• UserRepository receives the processed User
• User is transformed to UserEntity ( this could be implementation specific )
• UserEntity is saved locally in cache to be retrieved later.
  I hope this helps a bit.

edit was to reflect remark from @lalongooo made below.

Thanks @Trikke , I'll give it a try later today and let you know the results.

@lalongooo I have made an example for your need. Hope giving you some help. #55

@johnwatsondev It's a nice approach when passing a couple of params, but...what if you need to pass an object with a lot of properties/members..?

@Trikke If I let the SignUpUseCase to receive the Usermodel...wouldn't this be breaking the dependency rule?

I mean, the domain layer would be depending on a class of the presentation layer.

@lalongooo yes, i have made a mistake as was a bit too quick and forgot about the boundaries. In the Presentation Layer, you could have a mapper (something like UserModelMapper), which takes a UserModel from the Presenter and maps it to a User which the Domain will understand. This User is then passed as an argument to the UseCase. This way the Domain doesn't know about the data from Presentation, which is correctly converted at the boundary.

I'll adjust my comment above to reflect your correct remark.

@Trikke @lalongooo @android10 Hi everyone, IMO the implementation doesn't need the UserModel (Presentation layer) and it's mapper. The dependency rule states that nothing in an inner circle can know anything at all about something in an outer circle, but, the opposite is possible. I think it's possible to call the User (Domain layer) inside the presentation layer.
Plus, the UserModel and User have the same attributes. Technically, it's a dupicate and this is a violation of DRY. please correct me if i'm wrong.

The only thing I would add here is that a UserRepository should not know anything about signing up users, it is a repository and its responsibility is to work with data sources. The login process is part of your domain and the repository will "save" user session.

I think the UserModel and mapper is mechanical and dogmatic. If the user's data has changed(eg: add age attribute), you must change your user(UserMode-Presentation、User-Domain、UserEntity-Data) and its mapper in three layers，its unacceptable!
In MVP pattren, the model is an interface defining the data to be displayed or otherwise acted upon in the user interface. (Considering the layered architecture) Model is the embodiment of the data and business, and from the next layer of dependence. We can make it simple and dependency rules are correct, not so many template code(“user” and its "mapper").

@android10 You mean with "save" user session the request to the cloud but the domain model would create for example the preferences session for the user (login process)

@spirosoik yes. My comment was mostly a naming convention. A repository abstracts the origin of your data and should not know anything about login any user :)

@android10 exactly. Thanks great 👍 . By the way frodo rocks

@spirosoik 😄 Thank you!

@zhengxiaopeng what is your solution then?

@android10 :-) I am cognizing this question. The following is my view now:

• In M-V-X pattern and 3/N Tiers Architecture, the model classes(just model classes) are base on business rule and data access. Model classes may not be defined in presentation layer.
• "The models are likely just data structures that are passed from the controllers to the use cases, and then back from the use cases to the presenters and views." - The Clean Architecture, and Request model、Response model - Robert C Martin - Clean Architecture(42:46). So, remove the user's classes in presentation layer and then put them into domain layer. Mostly, one user model is enough.
• In data layer, conservatively, retain UserEntity. The data object class(UserEntity) is the starting point to solve the problem which user class violate DRY principle. but I think this should be specifically contemplated in the different application. @RamiJemli
• Otherwise, DTO pattern is a way for entity translator(some case).

Other reference:
Entity Translator
Using the Entity Framework in n-Tier Client-Side Applications
Using the Entity Framework in n-Tier ASP.NET Applications
mobile application development architecture

I'm a strong believer of having View Models and each layer should have its model to deal with. So I avoid coupling between layers. If you share Domain models with UI models, you are breaking the dependency rule because Domain knowing something about outer layers in the circle:

You will have to make changes anyway when adding new information to your UI.

Alright, I agree the dependency rule. I want to add that we(Android Dev) are just writing a single application, we don't have Front-end developer and Backend developer and so on. All codes(layers) are transparent to us。

@zhengxiaopeng I agree with you. @android10 Your great work got me interested in Clean architechture, so i looked deeper into this. When you call the domain model inside the presentation layer, it's the outer circle knowing something about the inner circle. This doesn't violate the dependency rule, but the opposite does.

@RamiJemli yup

Hello,

I don't if my question should be asked here (tell me if I'm wrong). My question is about using dynamic parameters in a use case, like @lalongooo I have a SignUpUseCase, and this use case need user's email and password.

If I take UserModule that have the responsibility to create GetUserDetails an Id is needed to get a specific user, And this Id is specified when UserModule is created.

private void initializeInjector() {
    this.userComponent = DaggerUserComponent.builder()
        .applicationComponent(getApplicationComponent())
        .activityModule(getActivityModule())
        .userModule(new UserModule(this.userId))
        .build();
  }

In my case when SignModule is created I don't already know the user's password and email, so I can't pass it through the constructor.

So how can I proceed to pass, user's email and password to my use case when the user hit the button create an account ?

This may help you @MehdiChouag #32

I'll take a look at this thank you 😄

What do you do when you have domain specific data? For example domain level entities have some metadata, while UI level does not need it. How do you save that metadata to be able recreate entity from UI level model?

Very interesting things going here.
Although this started a couple of years ago, I hope that some of you will comment on this:
What do you thing of making the DomainUser extends DataUser, and the PresentationUser extends DomainUser. Like this the Domain Layer can add more fields and functionalities without the Data Layer knowing about these additions. Also, the Presentation Layer will add functionalities and the Domain Layer will not know about them. This will not break the Clean dependency rule as inner layers are not aware the extends made by outer layers.

@lbensaad yes it would be breaking the dependency rule. DomainUser should not know about DataUser.

@ghost I have tried all three options you have mentioned! And I realized 2 is the simplest way. but that still has problems...according to bob's clean architecture, we must create a response model for presenter not DomainModel itself. And we must not send DomainModel to UseCase but Request model...so yea...