4 ms·

can anyone suggest links to reading about DDD & hexagonal architecture that clearly spells out: which context each pattern applies to ; what problem each patte

by shoo 5y ago

can anyone suggest links to reading about DDD & hexagonal architecture that clearly spells out: which context each pattern applies to ; what problem each pattern aspires to solve ; what advantages and disadvantages applying the pattern can have. bonus points for suggesting alternative patterns or linking to case studies / post-mortems / war stories / peer-reviewed empirical software engineering research of how these things turned out in practice. edit: here are some articles that are clearer: https://netflixtechblog.com/ready-for-changes-with-hexagonal-architecture-b315ec967749 https://netflixtechblog.com/ready-for-changes-with-hexagonal... https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-a...

a1445c8b 5y ago
If you’re using Python, I’d recommend Architecture Patterns with Python by Harry J.W. Percival and Bob Gregory.
berkes 5y ago
I presume you haven't read the "blue book"? Because that covers many of what you ask. In addition, the canonical (but not clearest, IMO) source on Hexagonal architecture is by the "inventor" himself: https://alistair.cockburn.us/hexagonal-architecture/ https://alistair.cockburn.us/hexagonal-architecture/. Several links in that article are dead now, but some still work and point to excellent discussions and articles. If you are looking "war stories" or "case studies" especially in a setting where management or colleagues need some convincing, this article of how Netflix employs it might help https://netflixtechblog.com/ready-for-changes-with-hexagonal-architecture-b315ec967749 https://netflixtechblog.com/ready-for-changes-with-hexagonal.... I've -depressingly, actually- found that often people are easier convinced by an argument "BigCorp™ does it too" than by "its good because of X". Recently a more practical post landed on HN. It includes CQRS, which might make it more convoluted than what you need, but even with that, it has some really nice "lessons learned" and "best practices": https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/ https://herbertograca.com/2017/11/16/explicit-architecture-0... (ninja-edit: weird sentence fixed)
- bruce343434 5y ago
  non-architect here, what is this blue book you allude to?
  - rapnie 5y ago
    "Domain-Driven Design: Tackling Complexity in the Heart of Software" https://www.oreilly.com/library/view/domain-driven-design-tackling/0321125215/ https://www.oreilly.com/library/view/domain-driven-design-ta... There's also "Domain Driven Design, Distilled" providing a comprehensive summary. https://www.pearson.com/us/higher-education/program/Vernon-Domain-Driven-Design-Distilled/PGM332632.html https://www.pearson.com/us/higher-education/program/Vernon-D...
    - cztomsik 5y ago
      haha, I know the book but the first one which came to my mind was this :-D http://wiki.squeak.org/squeak/64 http://wiki.squeak.org/squeak/64
- discreteevent 5y ago
  This book doesn't cover hexagonal architecture but I found it clearer and less verbose than the blue book. The first half of the book is on strategy and emphasizes its importance. It's a way of thinking that you can use with any architecture. It also makes it clear that only a subset of your system is suitable for DDD (not the CRUD bits for example). https://www.wiley.com/en-us/Patterns%2C+Principles%2C+and+Pr https://www.wiley.com/en-us/Patterns%2C+Principles%2C+and+Pr...
  - vladsanchez 5y ago
    Did you refer to [Patterns, Principles, and Practices of Domain-Driven Design](https://www.wiley.com/en-us/Patterns%2C+Principles%2C+and+Practices+of+Domain+Driven+Design-p-x000697634 https://www.wiley.com/en-us/Patterns%2C+Principles%2C+and+Pr...) by Scott Millet and Nick Tune? It's the only similarly titled Wiley book. Thanks for sharing.
regularfry 5y ago
Much though I dislike the author, I actually recommend the Clean Architecture book as an on-ramp for this stuff. CA is very similar to Hexagonal Architecture, and the book is more specific than any other source I've yet come across. It's written exactly with the goal in mind to tell you, clearly and unambiguously, what you should do and why, with as little room to manoeuvre as possible. That does make it a bit polemic, but when you're learning that's what you need. It's also worth looking at Vaughn Vernon's books on DDD. The problem there is that what you end up building if you follow them to the letter ends up looking a lot less like the sort of applications that teams are used to building (which is good! The value is proportional to the level of surprise) so getting buy-in at the right stage of the process to do it properly can be hard. You need to get in at the conception stage, so if your team is used to having ideas dropped on them even partially formed, the struggle is entirely non-technical. If you try to sell DDD as "how to structure the code we're going to write now that the problem has been thought through" it's not going to work.
leftshift 5y ago
It’s not a book, but I found this talk quite useful to help people grok DDD - “What I talk about when I talk about Domain-Driven Design” https://youtu.be/6nrRfCkeAKU https://youtu.be/6nrRfCkeAKU
scns 5y ago
Sadly not a blog post, but i can recommend this book [0] by Scott Wlaschin. Just finished it today, the last four chapters show how easy it is to incorporate changing business requirements. [0] https://pragprog.com/titles/swdddf/domain-modeling-made-functional/ https://pragprog.com/titles/swdddf/domain-modeling-made-func...
dagw 5y ago
When it comes to DDD, I highly recommend the book Domain Modeling Made Functional and the lectures the author has given based on the book: https://www.youtube.com/watch?v=9QlhkQl0DSw https://www.youtube.com/watch?v=9QlhkQl0DSw Those two resources where the ones the led to really get and appreciate DDD. One thing I really liked about them is that all the examples are in F# (the functional part of the title) and so manages to make it clear how DDD and OOP are decoupled and how DDD doesn't necessarily imply OOP.
- rapnie 5y ago
  Can absolutely recommend watching that video.

by shoo 5y ago

a1445c8b 5y ago

If you’re using Python, I’d recommend Architecture Patterns with Python by Harry J.W. Percival and Bob Gregory.

berkes 5y ago

I presume you haven't read the "blue book"? Because that covers many of what you ask. In addition, the canonical (but not clearest, IMO) source on Hexagonal architecture is by the "inventor" himself: https://alistair.cockburn.us/hexagonal-architecture/ https://alistair.cockburn.us/hexagonal-architecture/. Several links in that article are dead now, but some still work and point to excellent discussions and articles. If you are looking "war stories" or "case studies" especially in a setting where management or colleagues need some convincing, this article of how Netflix employs it might help https://netflixtechblog.com/ready-for-changes-with-hexagonal-architecture-b315ec967749 https://netflixtechblog.com/ready-for-changes-with-hexagonal.... I've -depressingly, actually- found that often people are easier convinced by an argument "BigCorp™ does it too" than by "its good because of X". Recently a more practical post landed on HN. It includes CQRS, which might make it more convoluted than what you need, but even with that, it has some really nice "lessons learned" and "best practices": https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/ https://herbertograca.com/2017/11/16/explicit-architecture-0... (ninja-edit: weird sentence fixed)

bruce343434 5y ago
non-architect here, what is this blue book you allude to?
- rapnie 5y ago
  "Domain-Driven Design: Tackling Complexity in the Heart of Software" https://www.oreilly.com/library/view/domain-driven-design-tackling/0321125215/ https://www.oreilly.com/library/view/domain-driven-design-ta... There's also "Domain Driven Design, Distilled" providing a comprehensive summary. https://www.pearson.com/us/higher-education/program/Vernon-Domain-Driven-Design-Distilled/PGM332632.html https://www.pearson.com/us/higher-education/program/Vernon-D...
  - cztomsik 5y ago
    haha, I know the book but the first one which came to my mind was this :-D http://wiki.squeak.org/squeak/64 http://wiki.squeak.org/squeak/64
discreteevent 5y ago
This book doesn't cover hexagonal architecture but I found it clearer and less verbose than the blue book. The first half of the book is on strategy and emphasizes its importance. It's a way of thinking that you can use with any architecture. It also makes it clear that only a subset of your system is suitable for DDD (not the CRUD bits for example). https://www.wiley.com/en-us/Patterns%2C+Principles%2C+and+Pr https://www.wiley.com/en-us/Patterns%2C+Principles%2C+and+Pr...
- vladsanchez 5y ago
  Did you refer to [Patterns, Principles, and Practices of Domain-Driven Design](https://www.wiley.com/en-us/Patterns%2C+Principles%2C+and+Practices+of+Domain+Driven+Design-p-x000697634 https://www.wiley.com/en-us/Patterns%2C+Principles%2C+and+Pr...) by Scott Millet and Nick Tune? It's the only similarly titled Wiley book. Thanks for sharing.

regularfry 5y ago

Much though I dislike the author, I actually recommend the Clean Architecture book as an on-ramp for this stuff. CA is very similar to Hexagonal Architecture, and the book is more specific than any other source I've yet come across. It's written exactly with the goal in mind to tell you, clearly and unambiguously, what you should do and why, with as little room to manoeuvre as possible. That does make it a bit polemic, but when you're learning that's what you need. It's also worth looking at Vaughn Vernon's books on DDD. The problem there is that what you end up building if you follow them to the letter ends up looking a lot less like the sort of applications that teams are used to building (which is good! The value is proportional to the level of surprise) so getting buy-in at the right stage of the process to do it properly can be hard. You need to get in at the conception stage, so if your team is used to having ideas dropped on them even partially formed, the struggle is entirely non-technical. If you try to sell DDD as "how to structure the code we're going to write now that the problem has been thought through" it's not going to work.

leftshift 5y ago

It’s not a book, but I found this talk quite useful to help people grok DDD - “What I talk about when I talk about Domain-Driven Design” https://youtu.be/6nrRfCkeAKU https://youtu.be/6nrRfCkeAKU

scns 5y ago

Sadly not a blog post, but i can recommend this book [0] by Scott Wlaschin. Just finished it today, the last four chapters show how easy it is to incorporate changing business requirements. [0] https://pragprog.com/titles/swdddf/domain-modeling-made-functional/ https://pragprog.com/titles/swdddf/domain-modeling-made-func...

dagw 5y ago

When it comes to DDD, I highly recommend the book Domain Modeling Made Functional and the lectures the author has given based on the book: https://www.youtube.com/watch?v=9QlhkQl0DSw https://www.youtube.com/watch?v=9QlhkQl0DSw Those two resources where the ones the led to really get and appreciate DDD. One thing I really liked about them is that all the examples are in F# (the functional part of the title) and so manages to make it clear how DDD and OOP are decoupled and how DDD doesn't necessarily imply OOP.

rapnie 5y ago
Can absolutely recommend watching that video.