Firstly I want to thank the Arrow team for such gr...
# arrow
i
Firstly I want to thank the Arrow team for such great libraries, I would like also to ask you for some help. My team uses Arrow since 0.13.2 back on May 2021. We started using it as a way to manage application errors in a functional way while we kept an OOish style, hexagonal arch, DDD and the "standard" BE stack of the company: Spring Boot and others. Will follow in thread.
With Arrow 1.0.1 we started a transition to reach a more FPish style and beside use of either for error managing we introduce Scopes and extensions receivers as a substitute for DI but maintaining hex arch (Controllers, Repositories, Usecases, Domain). Now with the recent Arrow 1.2.0 and the upcoming 2.0.0 we want to make the final assault but we are not sure Hexagonal + DDD is a good application design to accommodate Kotlin Arrow FPis style and the Effects system. Do you have any experience on that? Or online resources/books talking about Functional Domain Modelling and FP Aplication design for microservices and medium size teams? I mean things like Application Services and Domain separation in DDD is something natural in FP design? If not where are aspects like Transactions managed? Thank you very much in advance for your opinions on that.
r
I think that DDD and Hexagonal architectures are a good fit to combine with FP. I think as long as you stay away from global mutable state FP can mix nicely pretty much with anything. In terms of error handling with FP and hex architectures you usually follow a pattern to have a set of errors per layer and only the layer next to it knows and resolves them, resolving these errors and adding semantics at each layer where needed. This is usually modeled in a sealed hierarchy. As for dependencies and transactions these are what scopes in a way enable you to do, providing context that has a lifecycle. Personally I have seen at work multiple projects both in clients and internally that resemble something similar to what you describe Hex like architecture to abstract away concerns around interfaces and impls + DDD where most of the codebase is organized around the models.
❤️ 1
s
a
the design section in Arrow has a few articles about these topics https://arrow-kt.io/learn/design/
thank you color 1