This is a nice intro. Ports and adapters is such an awesome pattern, but you see it again and again that the terminology confuses people (it was evident in the live chat, too). And while I understand the hand-waving away of specific concerns, given that AC will have been using ports and adapters for the best part of a decade now, some real world practical “recipes” and model examples for different stacks could really help.
Yes, many developers have been requesting guidance regarding specific concerns about implementing Hexagonal Architecture. Alongside the TDD in Legacy Code series, there are also plans for Hexagonal Architecture in Legacy Code series - to give specific guidance about introducing Hexagonal Architecture. journal.optivem.com/p/tdd-in-legacy-code-transformation
Thanks Alistair. Nice one, appreciate it. Though you drew an ideal world picture and problems emerge when abstractions start to leak or when a port abstraction boundary is wrong
I got one question... When you have driven adapters outside the app, and they are mocked up in the tests... Should not the driven adapter-code be tested ? Or should they be tested seperatly ?
I asked about optimistic locking and transactions and @Rob van der Linden Vooren asked a similar thing about propagating context from/to adapters. Unfortunately, the answer is "I don't care". This sounds like an "ivory tower" architecture to me...
Hi! I'm not really used to this specific approach, but I do try to isolate interfaces and their responsibilities in my work, so what Alistair says landed nicely in my mind. To try to figure out some working design of the interfaces, I'd start by asking questions like this to myself: For passing of the context: is it an important part that should be accessed and used in the app itself? I'll make it a part of each interface then (both driving and driven). Or is it an implementation detail? Then I'd try to delegate this to the supporting libraries, to make it a sideband context and then work on supporting it on all types of the adapters (which can be a tedious task and it would be an easy thing to lose). If there is no way to do that in the language/ecosystem, then only option A is left. For supporting a transaction or distributed transaction: Is it an important part of the app itself? I'd expose the transaction control on the driven interfaces and make some kind of transaction manager your required dependency. Then wire it up in the app configuration, so it would control all the driven interfaces that need that management. Or is it just an implementation detail? Then I'd make the transaction control a part of your adapter that would expose only "Save" method on the complex object to the app and do all the work without exposing the complexity of the actual storage. For optimistic locking: Is it important to the application? I'd expose the "Update" method with both expected and desired state of the object as the parameters and make it properly return the updated state with failure status or success status as a result Is it an implementation detail for which I can figure out the automatic resolver of the conflicts? Then I'd expose the "Update" method with the set of desired changes to the object state What do you think, should these approaches and this way of thinking work?
This is a nice intro. Ports and adapters is such an awesome pattern, but you see it again and again that the terminology confuses people (it was evident in the live chat, too). And while I understand the hand-waving away of specific concerns, given that AC will have been using ports and adapters for the best part of a decade now, some real world practical “recipes” and model examples for different stacks could really help.
Yes, many developers have been requesting guidance regarding specific concerns about implementing Hexagonal Architecture.
Alongside the TDD in Legacy Code series, there are also plans for Hexagonal Architecture in Legacy Code series - to give specific guidance about introducing Hexagonal Architecture.
journal.optivem.com/p/tdd-in-legacy-code-transformation
What a co-incidence - I got interested in Hexagonal Architecture today and this was streamed yesterday
Thanks Alistair. Nice one, appreciate it. Though you drew an ideal world picture and problems emerge when abstractions start to leak or when a port abstraction boundary is wrong
brilliant channel
I got one question...
When you have driven adapters outside the app, and they are mocked up in the tests...
Should not the driven adapter-code be tested ?
Or should they be tested seperatly ?
I asked about optimistic locking and transactions and @Rob van der Linden Vooren asked a similar thing about propagating context from/to adapters. Unfortunately, the answer is "I don't care". This sounds like an "ivory tower" architecture to me...
Hi! I'm not really used to this specific approach, but I do try to isolate interfaces and their responsibilities in my work, so what Alistair says landed nicely in my mind.
To try to figure out some working design of the interfaces, I'd start by asking questions like this to myself:
For passing of the context: is it an important part that should be accessed and used in the app itself? I'll make it a part of each interface then (both driving and driven).
Or is it an implementation detail? Then I'd try to delegate this to the supporting libraries, to make it a sideband context and then work on supporting it on all types of the adapters (which can be a tedious task and it would be an easy thing to lose). If there is no way to do that in the language/ecosystem, then only option A is left.
For supporting a transaction or distributed transaction:
Is it an important part of the app itself? I'd expose the transaction control on the driven interfaces and make some kind of transaction manager your required dependency. Then wire it up in the app configuration, so it would control all the driven interfaces that need that management.
Or is it just an implementation detail? Then I'd make the transaction control a part of your adapter that would expose only "Save" method on the complex object to the app and do all the work without exposing the complexity of the actual storage.
For optimistic locking:
Is it important to the application? I'd expose the "Update" method with both expected and desired state of the object as the parameters and make it properly return the updated state with failure status or success status as a result
Is it an implementation detail for which I can figure out the automatic resolver of the conflicts? Then I'd expose the "Update" method with the set of desired changes to the object state
What do you think, should these approaches and this way of thinking work?