10 ms·
Ready for changes with Hexagonal Architecture
- aprdm 7y agoWonder if they have some source code examples, this also seems very similar to DDD.
- manigandham 7y agoHexagonal, Domain-driven, Onion, Clean architecture are all synonyms at this point. Core libraries for shared utilities and domain objects, next layer is business logic, then outer layer of interfaces to everything else like databases and webservers.
- rumanator 7y ago> Hexagonal, Domain-driven, Onion, Clean architecture are all synonyms at this point. There are important differences between, say, hexagonal architecture and clean architecture. For instance, in clean architecture, what the Netflix guys described as repositories would actually be the data source itself and represent yet another interface on the system's outer layer. Additionally, what the Netflix guys described as interactors would actually be the application layer, and it would be the only layer above the entity layer (i.e., activities don't depend on data source components)
- m2mdas2 7y agoI have been following hexagonal architecture recently, found some good references, * This article 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... have detailed explanation on the components of hexagonal architecture. * There is COLA framework https://github.com/alibaba/COLA https://github.com/alibaba/COLA based on spring boot from Alibaba. Description is in Chinese but google translate does good enough translation. There is some pretty interesting things happening in Chinese universe that are hidden for language barrier. * Another sample application in .NET https://github.com/kgrzybek/modular-monolith-with-ddd https://github.com/kgrzybek/modular-monolith-with-ddd which gives good overview of code architecture.
- vosper 7y ago> There is some pretty interesting things happening in Chinese universe that are hidden for language barrier. Are there any other things you can point to that you think are overlooked?
- m2mdas2 7y agoI occasionally check trending repositories of chinse language in github https://github.com/trending?spoken_language_code=zh https://github.com/trending?spoken_language_code=zh and github repositories of Alibaba, tencent etc. From the look of it they are very focused on tooling/tutorials on highly salable distributed systems architecture. Java is very popular and spring cloud is their preferred choice. One thing I found interesting is that hibernate ORM is not used anywhere, instead they prefer MyBatis data mapper framework. Some of those projects are moved to apache foundation. On top of my head I found these projects interesting, * Dolphin Scheduler https://github.com/apache/incubator-dolphinscheduler https://github.com/apache/incubator-dolphinscheduler * Echarts https://github.com/apache/incubator-echarts https://github.com/apache/incubator-echarts * Ant Design https://ant.design/ https://ant.design/ * Sky walking APM https://github.com/apache/skywalking https://github.com/apache/skywalking * Seata distributed transaction system https://github.com/seata/seata https://github.com/seata/seata * EasyTransaction distributed transaction system https://github.com/QNJR-GROUP/EasyTransaction https://github.com/QNJR-GROUP/EasyTransaction * EShop-SOA https://github.com/songxinjianqwe/EShop-SOA https://github.com/songxinjianqwe/EShop-SOA * RocketMQ https://github.com/apache/rocketmq https://github.com/apache/rocketmq * Sharding Sphere https://github.com/apache/incubator-shardingsphere https://github.com/apache/incubator-shardingsphere * Jeecg-Boot https://github.com/zhangdaiscott/jeecg-boot https://github.com/zhangdaiscott/jeecg-boot * SOFA Stack https://github.com/sofastack https://github.com/sofastack * Dubbo RPC framework https://dubbo.apache.org/en-us/ https://dubbo.apache.org/en-us/ . Also it seems that every big companies in China have their own RPC framework.
- deleted 7y ago[deleted]
- hinkley 7y agoHmm. Maybe Webstorm 2021.1 should have comment translation as a feature.
- charlieflowers 7y agoAlso called "Functional Core, Imperative Shell." Good talk: https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries
- insulanian 7y agoIt's a well established software architecture approach, especially in the enterprise software area. It works well with OOP as well as with FP. Highly recommend it.
- dangets 7y agoMicrosoft also published a good series of articles on DDD / CQRS / Hexagonal architectures [1]. I especially like the diagrams of dependencies between layers on that linked page. [1] https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/ddd-oriented-microservice https://docs.microsoft.com/en-us/dotnet/architecture/microse...
- orthoxerox 7y agoI prefer to have an additional layer that is usually called the service layer. You use it to express and orchestrate the actions of your application without hard dependencies on specific tech. So the application layer is the one that manages specific dependencies and injects them into the service layer and the service layer then goes: - okay, when asked to disburse a loan - I construct a domain object for the loan - If the object is valid, I make a sync call to deposit the money - I then persist the loan - I then send a notification that a loan is disbursed And it doesn't really know how the RPC, the notification, or the persistence layer actually work.
- SmooL 7y agoI love the idea, and maybe this works well for them in a position of relatively lax performance. The truth is that all abstractions around data fetching are inherently leaky; making an API call does _not_ have the same runtime characteristics as reading from a file. Different access patterns have different performance implications across different data sources. I would love if somehow we could put runtime performance characteristics in the type systems. Implementing readFile<T extends Readable, S extends SomeRuntimeCharacteristic> would go a long way towards sealing those leaks.
- adamkl 7y agoIt’s all about the right tool for the job. I always push this approach when developing applications, but I work in large enterprise where performance often isn’t critical, but applications can live on for _decades_. Should you use this approach when developing something like nginx? Probably not. But if you are developing a line-of-business application that has to interact with an ever-evolving mish-mash of other systems over an embarrassingly long time frame, it’s a great approach.
- cheez 7y agoThis sounds like something a politically astute developer came up with and built short-term career growth on it at Netflix while the rest of the developers at Netflix look on and say "yeah ok but that's just <FOO METHOD> drawn like a hexagaon. AM I THE ONLY ONE WHO SEES THIS ISNT SPECIAL????" (Because of course, I created something like this more than a decade ago that is still in use)
- wpietri 7y agoThe term was invented something like 15 years ago by Alistair Cockburn. https://en.wikipedia.org/wiki/Hexagonal_architecture_(software) https://en.wikipedia.org/wiki/Hexagonal_architecture_(softwa...
- mpweiher 7y agoAnd the post even has a link to the wikipedia entry when it introduces the term...
- cheez 7y agoThe originality is not really relevant. I've seen this type of thing take place before.
- wpietri 7y agoIt is in fact relevant to your claim that it sounds like somebody came up with it as a career advancement technique. Rather than it being part of a decades-long dialog about how to build software.
- cheez 7y agoAh, I seem to have have met the politically astute developer on HN. You might like this version better https://news.ycombinator.com/item?id=22566315 https://news.ycombinator.com/item?id=22566315
- 7y ago
- UK-Al05 7y agoPeople have been using this for years. One of things I recommend is not using the repository pattern. You end up with a repo with lots of methods on and overly generic. For each of the use cases/interactors, any database action should be wrapped up in a specific interface for that database action. Then implement those database interaction by implementing that interface. Query and command objects instead of repos. Much finer grained then repos. Also allows for finer grained control over which data source you use for each interaction.
- HelloNurse 7y agoIt depends. Sometimes a repository can cover all needs with relatively few and relatively generic methods, sometimes specialized database interactions can be application logic layered on top of a much less specialized repository, sometimes a repository becomes unpleasant because it should be split up, etc.
- adamkl 7y agoI came across an article a few weeks ago [1] that distils the idea of this architecture into a very simple pattern, stratified design, or the “Integration Operation Segregation Principal”: “A function either integrates or operates, it either only calls other functions or it does not call other functions but contains only logic.” Basically, you have code that interacts with the outside world, and you have logic (read: conditionals and branching). Don’t mix the two. It’s such a simple concept that it seems obvious in hind-sight (so maybe that’s why nobody ever talks about it, because it is obvious), but I don’t see code written this way all that often. If there’s one thing I could teach every new developer it would be this. It’s such a little thing, but it would make a lot of code much easier to work with. [1] https://medium.com/clean-code-development/stratified-design-over-layered-design-125727c7e15 https://medium.com/clean-code-development/stratified-design-...
- chris_st 7y agoWow, thanks, that's a fantastic article, particularly because it shows actual code that illustrates the idea, instead of being overly abstract.
- veeralpatel979 7y agoFunctional core, imperative shell is how this is commonly described! https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell https://www.destroyallsoftware.com/screencasts/catalog/funct... https://news.ycombinator.com/item?id=18043058 https://news.ycombinator.com/item?id=18043058
- eternalban 7y agoThe article begins with a misunderstanding. The semantic symmetry of the OSI layers is clearly an 'interaction': there is a computer talking to another computer. The stack diagram is obviously only considering a single object, a system. Would not be surprising that should we introduce the 'user' as the peer to the system that we can in fact derive a similar symmetry in layers. Yes, the user side of the layers would be mostly logical 'organizational' concerns.
- 7y ago
- Communitivity 7y agoI 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.
- sischoel 7y agoSome thing I was wondering about this kind of architecture, how would you express some constrains, like foreign key constraints or unique key constraint? Would they still be in the database, or would you put them into some inner layer?
- deleted 7y ago[deleted]
- kgwxd 7y agoMy understanding is that only the storage layer should care about that, and only if it's a relational store. The concept of looking things up by "id" will obviously make it to the application layer but the application layer "id" isn't directly linked to the PK column of a particular SQL table, even if it's going to be the most common use case.
- duke360 7y agocool... but it is not hexagonal, it is almost quadrilateral :D :D
- jmartrican 7y agoThis architecture might bring back monoliths. Or at least it'll bring back monolith first.
- michael_j_ward 7y agoIf someone has some good, open source examples- please share!
- saagarjha 7y agoI guess I’ve been staring at LLVM CMake output for too long, because I thought this had something to do with https://en.wikipedia.org/wiki/Qualcomm_Hexagon https://en.wikipedia.org/wiki/Qualcomm_Hexagon