Clean architecture

[Jop van Raaij]

Inspired by the video on architecture, the lectures of Uncle Bob about 'architecture, the lost years' and the article http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html, I try to create a 'clean architecture' using TDD and have the Entity Interactor Boundary pattern in mind.

I'm having trouble getting things into the right perspective. Suppose I've been working on an application with authentication and start working on a second application, also using authentication. Both use a username as 'identifier' and a password which determine if a user is authenticated or not. In the first application there is some logic in the interactor AuthorizeUser. This logic is now candidate for extraction to an 'Authentication' module. To facilitate communication to the Authentication module, there are two interfaces: UserAuthenticator and AuthenticationResultProcessor. To pass the information about the user, a User TO class is present in the module.

The Authenticator module code is as follows

class AuthenticateUser implements UserAuthenticator {

private AuthenticationResultProcessor authenticationResultProcessor;

public AuthenticateUser(AuthenticationResultProcessor authenticationResultProcessor) {

this.authenticationResultProcessor = authenticationResultProcessor;

}

public void authenticate(User user) {

boolean authenticated = false;


//determine whether the user is valid and set authenticated to true or false;
authenticationResultProcessor.setAuthenticated(authenticated);

}

}

interface AuthenticationResultProcessor {

boolean isAuthenticated();

}


interface UserAuthenticator {

authenticate(User user);

}

class User{

String identifier;

String password

}

The application will now call the authenticator module (probably delegating from the existing AuthenticateUser interactor) by implementing the AuthenticationResultProcessor and passing it to AuthenticateUser class on creation. After calling authenticate(user), it will be able to ask the AuthenticationResultProcessor isAuthenticated() to determine the state of the authentication.

Naming of the classes/interfaces might be improved. I tried to name the interfaces from the perspective of the client. Besides that, I'd really like to know if I am on the right track for creating application independent modules. Maybe I'm forcing too much towards the EIB pattern? Opinions are appreciated a lot!

[Uncle Bob]

Your 'AuthenticateUser' class (which I agree could be better named) nicely separates the knowledge of _how_ to authenticate from the knowledge of _what_ to do with that authentication.  So AuthenticateUser is application specific and belongs on the interactor side of the equation.  It might even _be_ an interactor, though I don't see the boundary connections that I'd expect; so I reckon it's a tool used by an interactor.  The implementation of AuthenticationResultProcessor will also be application specific, and probably live in a database or data handling plugin.  The 'User' class appears to be a data structure coming from the UI, as such it could use a better name too.  What's missing is the notion of an 'entity' that represents the user.  Is there an application independent class that represents the user that this interactor could create based upon authentication?

Overall, I think you are on the right track with the separation of concerns.  Let's see a few more use cases.