3 ms·
I was disappointed that the article didn't mention Alistair Cockburn, who came up with this architecture style, which is also sometimes called ports and adapter
by Communitivity 7y ago
I was disappointed that the article didn't mention Alistair Cockburn, who came up with this architecture style, which is also sometimes called ports and adapters. I like hexagonal architecture a lot, but I change one aspect. Instead of Interactors I use composable Functors and Pipes. A Functor is an Interactor that takes in one Entity and produces an Entity. A Pipe is software that implements one of the different Router patterns from Enterprise Integration Patterns (https://www.enterpriseintegrationpatterns.com/patterns/messaging/MessageRoutingIntro.html https://www.enterpriseintegrationpatterns.com/patterns/messa...). I guess you'd call what I use a hybrid of the EIP style and the Hexagonal style.
- BoiledCabbage 7y agoThis sounds really interesting, and reminds me of "Domain Modeling Made Functional". But could you describe the pipes a bit more? EIP from the link your provided says that any interactor/filter in a pipe is interchangeable with another. Based on the model you described you say you'd have each interactor take in an entity and output a possibly different entity (which seems reasonable). But if you did that and had a chain of interactions, then removed one from the middle wouldn't you now have a type mismatch where you try to connect the remaining interactions?
- Communitivity 7y agoGood question. You're right in that the Interactors can only be chained according to their types. Let's say I had an A->B, C->D, B->C, and C->E. I could form a chain (A->B)->(B->C)->(C->D), but I couldn't do (A->B)->(C->D). The Pipes come into play for routing, splitting, and combining. I can use [] as syntax for a splitter and => for a combiner. The combiner is used in conjunction with {} to represent an input that's a combination of the inputs inside of it. I can then represent textually a pipeline to produce F from A with functors (the 1-1 Interactors), a combiner pipe and a splitter pipe. (A->B)->(B->C)->[(C->E), (C->D)]=>({E,D}->F). As a side note, you can tell I like to make sure I can have a textual syntax for describing things..let's you process it with sw and I am horrible at graphics. Regarding interchanging the different, I think it means you can swap a router for an interactor, or vice versa, as long as the types match. It's basically enterprise architecture level functional programming, kind of.
- BoiledCabbage 7y agoI like your approach to problem solving - it's very similar to mine and in domains I also think about. Your syntax is very convenient thanks for sharing. And finally, I assume you're familiar with Scott Wlashin (of F# for fun and profit & "Domain Modeling Made Functional")[1][2]. If not you 100% should read it as it is right up your alley. It's the intersection of Functional Programing and DDD/EIP. (I have no affiliation). [1] https://fsharpforfunandprofit.com/ddd/ https://fsharpforfunandprofit.com/ddd/ [2] https://www.amazon.com/Domain-Modeling-Made-Functional-Domain-Driven/dp/1680502549 https://www.amazon.com/Domain-Modeling-Made-Functional-Domai... [3] https://fsharpforfunandprofit.com/rop/ https://fsharpforfunandprofit.com/rop/ (Railway oriented programming)
- Communitivity 7y agoThanks, for the compliment and for the links. I wasn't aware of him until now. I've little experience with the X# family, other than some Mono hacking on an OpenSim clone. Sounds interesting and will definitely read at least the Domain Modeling one, possibly the F#s too (never too late to add a piece of kit to your toolbox).