Achieving clean architecture using EBI pattern

[Dhaval Shah]

Business Scenario -

1. I am required to develop an application which requires user registration in which 

          - user id is verified by an external system (LDAP based)

          - loyalty cards are shown to the user on successful registration

2. Variations w.r.t user registration are -

1. User registration via mobile app
2. User registration via web application
3. User registration via web application (UI) developed by some other vendor

 

Solution (as per my understanding of 3 layered architecture) -

1. Have 3 controllers for all the above 3 variations -
1. Mobile App API Controller for catering to mobile app based requests, having mobile specific header info viz. device information, product version, app version etc
2. Web application Controller tightly coupled with the form (i.e. ModelAttribute of Spring) as UI is owned by our system
3. Web application API Controller (as web UI is not owned by us) which will have request parameters with headers specific to browser (i.e. without device information, product version, app version etc)
2. Each of these controllers call common validation component and then convert the request object to domain object which is then passed on to the service/business layer for business workflow processing.
3. After business workflow processing, service/business layer passes domain object to LDAP Adapter component which then converts domain object as per the LDAP contract and sends it to LDAP system
4. LDAP on successful user verification, gets the loyalty cards associated with the user from other backend system. LDAP Adapter converts loyalty card data to domain object and then control returns to service / business layer with domain object of loyalty cards. Thereafter service / business layer passes user info domain object and loyalty card domain object to repository for persisting in database.
5. Repository first converts both the domain object (i.e. user profile and loyalty cards) to db entity (as per the underlying OR framework) and then persists in to the database.
6. On successful creation of user profile and its related loyalty cards, control returns from repository to service / business layer. Business layer then returns to controller along with loyalty card domain object
7. Respective controller converts the loyalty card domain object to appropriate response object as per the source of request i.e. either mobile app or web application owned by our system or web application (UI) developed by some other vendor.

Query

Based on my limited understanding this implementation is not aligning with clean architecture. Hence I would appreciate if clean code aficionados can help me understand how can I achieve above solution in such a way that it aligns with clean architecture principles using Entity - Boundary - Interactor pattern?

Thanks in advance.

[Dhaval Shah]

Request all the members to help me understand how clean architecture principles be applied to the below scenario.

[Sebastian Gozin]

If you were asked to make this work with 2 or more different persistence strategies. For the sake of the argument one simply stores the account details in memory and the other in LDAP. (other suggestions could be the file system or SQL)
Now how would you go about meeting the requirement of being able to swap the persistence strategy while reusing the business rules such as validation etc...

One remark though.
You mention business workflow processing as if it's normal something is done there but I can't possibly imagine what more you'd need other than account registration request validation and then creating the actual account.
Both of which are already covered outside of this business workflow processing.

Though I did see things like loyalty cards so perhaps you're referring to setting up additional account related resources. Possibly based on details from the account registration request.
Anyway, I'm not going to speculate too much on that.

Sebastian

[Dhaval Shah]

Thanks Sebastian.

By business workflow I meant that on successful user registration, there would be bunch of loyalty cards that would be fetched from loyalty card system. And each of these loyalty cards will be getting mapped against the corresponding user.

However, what I am still unable to figure out is - Using Clean Architecture principles, how to implement presentation layer such that it caters to 3 distinct ways (i.e. mobile app, web application and application with UI as different tier/enterprise application) of accessing services (as mentioned below)?

Regards,

Dhaval Shah