I think a combination of "elements of clojure" and "clojure applied" would address this, though not by name. That's assuming you have covered the basics in a book like living clojure, or a more comprehensive set like in joy of clojure

To me, ports and adapters seem like something you need to escape OOP, and think that in clojure something similar should be possible with a simpler model, e.g here my "ports" are just keywords: https://github.com/polymeris/edos

Thank you guys. @U0DJ4T5U1 I did read Joy of Clojure. @U0FTV149X edos looks interesting. A bit macro heavy for my taste. But interesting.

Yeah, it's just an experiment. I think a better approach would be more data-driven

This is another talk that touches on the same topics: https://www.youtube.com/watch?v=WtdegIqQbrg

The whole talk is interesting, but you can skip to 15m to see how they handle "commands" and isolating side-effects

Did watch that one. That's what started me to really think about how ports and adapters would combine with state machines to give us a framework to organize code

I am sure there is a lot of research an experimentation to be done.

Let us know if you come up with interesting ideas!

Will do!

Well, from my quick read of the pattern, I would say the goal is to increase the understandably of the code base though separation of concerns. That idea is applicable in clojure as well. I wouldnt conflate business rules with http calls for example.

The difference in implantation would be that where in oop, your encouraged to see your objects as data stores, the clojure community would suggest maps or possible datomic or datascript to hold the information

So your http call might return a resp, then a validation, then a conversion fn to the business domain, then this data can enter the business domain api

At https://github.com/DomainDrivenArchitecture we do DDD with clojure. Aggregation, validation and bounded contexts are working quite well to us (way smarter than OO :). We're very interested in discussing functional-DDD adoption 🙂