Timeline for How should infrastructure be able to reference repository interfaces in onion architecture?
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 22, 2020 at 12:04 | vote | accept | tenstan | ||
| Jul 22, 2020 at 11:41 | answer | added | Flater | timeline score: 4 | |
| Jul 22, 2020 at 11:23 | comment | added | Flater | @ZeHans: What you have is a normal dependency. What Jeffrey Palermo is talking about is an inverted dependency. Both work, but they are different concepts. When dealing with inverted dependencies, the domain is concerned with setting the requirements for what they expect to be able to do with e.g. an IRepository. For example, the domain can essentially demand that "repositories must be able to create and delete, but I will never try to update something". Then it's up to the Infrastructure layer to comply with the demands as defined by the DomainServices.IRepository interface. | |
| Jul 22, 2020 at 9:59 | comment | added | tenstan | @RikD You are right. I'm going to take all this more pragmatic when I'm building my project or I'll be stuck 90% theorizing and 10% actually writing code. | |
| Jul 22, 2020 at 8:44 | comment | added | Hans | @octagon_octopus My business logic doesn't depend on any interfaces. And even if it did, I could just swap implementations in my DI container. That is why the question "Where to put interfaces" seems rather arbitrary to me, but I might be missing something. | |
| Jul 22, 2020 at 7:17 | comment | added | Rik D | @octagon_octopus remember that books, blogs, tutorials and sample projects are explaining architectural principles. You learn from them, but only use what makes sense when you need it. Don’t be dogmatic about any software principle. | |
| Jul 21, 2020 at 22:56 | comment | added | tenstan | @RossHalliday I have seen example projects like that indeed. The issue I had with that is that a lot of people take various different approaches. The NorthwindTraders project for example chooses to split the ApplicationCore into two separate projects Application and Domain. I definitely should and already planned on reading some books, hope to get around that soon. | |
| Jul 21, 2020 at 22:45 | comment | added | tenstan | @RikD You are right, I read part 1 carefully again and it does say Another key difference is that the layers above can use any layer beneath them, not just the layer immediately beneath. It just does not make sense how that can allow UI to do whatever with domain logic, although I suppose he might've chosen to leave out stupid ideas like that. | |
| Jul 21, 2020 at 22:37 | comment | added | Ross Halliday | Alternatively read Uncle Bob’s “Clean Architecture” it’s very good at explaining it all ;-) | |
| Jul 21, 2020 at 22:36 | comment | added | Ross Halliday | You’re maybe taking his diagram too literally. In net core we have an “application core” project which contains the domain model, domain services, application services and interfaces; essentially all of the testable business logic. Then there is an “Infrastructure” project which holds all of the concrete implementations of the interfaces; this is generally database connections; http clients, message queues; all the stuff that you can’t or don’t want to unit test. Over this usually sits a “web” project where net core wires up the “application core” to the “infrastructure” | |
| Jul 21, 2020 at 22:27 | comment | added | Rik D | ’The fundamental rule is that all code can depend on layers more central’. Notice it’s plural. He doesn’t say code can only depend on the layer directly above, but all layers above (to the center). What’s more important is that no code can depend on lower layers. | |
| Jul 21, 2020 at 21:45 | comment | added | tenstan | @ZeHans Say if you want to switch from a MySQL DB to a Postgres DB, then you would have to modify your business logic as well, because your business logic depends on the interfaces that are defined with the MySQL implementation. For that reason it could be useful to place your interfaces in a layer more towards the center. I will join you in that I don't see how they solve a domain concern though. | |
| Jul 21, 2020 at 21:22 | comment | added | tenstan | @RikD not completely. In part 2, Jeffrey seems to take the exact approach that he had written as theory in part 1. He implements the interface in Domain Services and puts the implementation in Infrastructure, when that shouldn't be possible when I look at his Onion Architecture model. It seems to me that he sees the "Application Core" as 1 layer, instead of 3 separate layers, but then I don't see what the separation is for. | |
| Jul 21, 2020 at 20:34 | comment | added | Hans | I have my repository interfaces sitting right next to the implementations - in the infrastructure layer. They are coupled by a DI container. Not sure why it would be so advantageous to put the interfaces in the domain layer. To me, they don't represent a domain concern. | |
| Jul 21, 2020 at 20:20 | comment | added | Rik D | Does this answer your question? jeffreypalermo.com/2008/07/the-onion-architecture-part-2 | |
| Jul 21, 2020 at 19:27 | review | First posts | |||
| Aug 3, 2020 at 6:32 | |||||
| Jul 21, 2020 at 19:25 | history | asked | tenstan | CC BY-SA 4.0 |