How do we derive the Hexagonal Architecture diagram presented by Alistair Cockburn? How do we apply Hexagonal Architecture in designing a sample eCommerce system? What about the layers inside?
In an MVC app, yes, the MVC controllers are the presentation layer and tbhe application services are the business layer.
In a frontend + backend application, we can apply HA to frontend, and apply HA to backend. When applyiing HA to backend, the REST API controllers are the presentation layer within the backend HA.
I'm quite fond of bringing Hexagonal Architecture together with Clean Architecture into software development. These two styles promote the idea of business logic independence, allowing the core of the application to be agnostic to any external influences, such as UI, databases, or external agents.
Alongside these architectures, I exercise caution with the Specification Pattern. This pattern is a powerful tool when dealing with complex business rules, as it encapsulates them into a separate, reusable, and combinable object. It fits nicely into the purpose of keeping business logic at the center of the design, clearly separated from other concerns.
Is the frontend the presentation layer and is the back the business layer?
In an MVC app, yes, the MVC controllers are the presentation layer and tbhe application services are the business layer.
In a frontend + backend application, we can apply HA to frontend, and apply HA to backend. When applyiing HA to backend, the REST API controllers are the presentation layer within the backend HA.
Let me know if this answers yor question...
I see. Does the Hexagonal Architecture algo Apple to a frontend application?
Wow, excellent post! Direct to the point and very educational. Thanks for sharing!
I'd be interested in hearing your perspectives about Hexagonal Architecture, or any other architectural styles you have adopted. Have a good day!
I'm quite fond of bringing Hexagonal Architecture together with Clean Architecture into software development. These two styles promote the idea of business logic independence, allowing the core of the application to be agnostic to any external influences, such as UI, databases, or external agents.
Alongside these architectures, I exercise caution with the Specification Pattern. This pattern is a powerful tool when dealing with complex business rules, as it encapsulates them into a separate, reusable, and combinable object. It fits nicely into the purpose of keeping business logic at the center of the design, clearly separated from other concerns.
"These two styles promote the idea of business logic independence" - spot on, yes, that's the main reason why I use these architectures too.