Clean Architecture => DDD Application Services layer VS Interactors layer

[Michael Azerhad]

Hello Uncle Bob :)

I've just watched a great conference where you talked about your way of thinking about Clean Architecture: http://www.youtube.com/watch?v=asLUTiJJqdE

You explained that any heart software should be completely independent of any delivery mechanism (DB, kind of UI etc...) => totally agree.

That's why you outline the need of an Interactor layer, representing any uses cases with pure data structures as input and pure data structures as output.

Currently, I develop a personal project using Hexagonal Architecture (following Domain-Driven Design). 

Does the Application Services layer, in DDD sense, play the exactly same role as your Interactor layer (Use-Cases layer)?

Indeed, each application service deals with data structures as input (simple DTO in my case), and returns others. Each service represents a use-case and the whole is well testable quickly with data only in memory without any "details" like controller or anything else. Thus, it seems to be very similar with your definition of "Interactor layer". 

Did I missed something ?

Thanks a lot :)  

Michael

[Uncle Bob]

Michael,

You didn't miss anything.  There is a difference in emphasis between the two architectures, but no difference in substance.  DDD emphasizes the domain -- ergo "Domain Driven".  The Clean Architecture emphasizes the Use Cases, the services.  Jacobson called it "Use-case driven".    It's not really important which of the two drives.  What is important is that the two are kept separate. If the domain drives, you might not get crisp divisions between your use cases; and so the service layer may appear muddled.  If the use caes drive, you may not get crisp divisions between your domain elements, and so the domain model may appear muddled.  It is the designers job, in each case, to prevent that muddle by viewing the design from the opposing view from time to time.
 

[Michael Azerhad]

Thanks :)

Until now, my service layer is also responsible to convert some results into some appropriate DTO's, consumable by my UI part.

So, if I well understand, I should separate this "out-of-use-case" notion. Possibly making a kind of another layer (a facade), out from use-cases, dealing with DTO conversion. This facade would merely delegate calls to use-cases. 

Or, another way of doing, make each use-case notify my presenters (with boundary interface only), as you outlines in your PPT on clean architecture.