No fancy RGB background lights, no fancy cuts or animations. Only what's important: Knowledge delivered simply. Appreciate your video very much. Subscribed to get future videos 🙌
This was a really good overview, especially considering the length. Framing Dependency injection as connecting/swapping similar puzzle pieces is a really intuitive way of expressing the concept. Only so much you can do in 10 minutes, but would have been nice to see more about inversion of control and how modeling software like this allows us to write durable tests for our application layer more easily. Looking forward to seeing what you put out in the future!
Here's another great overview, in 4 mins: czcams.com/video/JubdZIdLQ4M/video.html Followed by a terrific explanation of Aggregates, Entities, Value Objects and Domain Events: czcams.com/video/xFl-QQZJFTA/video.html I'm not affiliated, I just found them really helpful
Really nice job! So those puzzle piece holes that you mentioned: are those implemented using interfaces? Would love to see a real code example of how to achieve those holes and how boundaries are achieved (Dependency Inversion?)
Yeah so the hole would be an interface and the puzzle price would be an implementation. I wanted to keep it generic and language-agnostic for this first one but I definitely am planning on doing some much more specific code examples.
Excellent video with superb visulazation to explain it in a very simple and elegant way, Thanks a lot. As a side note would you like to share what tech gadget you are using for drawing and displaying those diagrams?
i appreciate your content ,i love this video,thax Iwould like to know how u make video ,writing on screen and it appears on video in same time ,i like this
Thanks! I'm glad you liked it! For writing on the screen, I used the Microsoft Whiteboard app with a pretty basic pen input and just layered them together in OBS Studio using a luma key filter to remove the background.
That's silly changing the db from say relational to NoSql won't ripple through the stack. Think of any application consuming a third party api that's consuming a database. The Api layer necessarily protects is meant to encapsulate / abstract details from the the client's using it
The jigsaw puzzle pieces are shown in the application layer, however the repository interfaces (also jigsaw puzzle pieces) are typically defined in the domain layer, so does this mean the domain layer also allows things to be plugged in like the repository implementations. In the diagram above the sql repository implementation is shown plugged into some application service but wouldnt it get plugged directly into the domain layer if the IRepository interface has been defined in that layer
Where to put repository interfaces is open for a bit of a debate. Sometimes you'll see a "Domain Services" layer in-between the domain layer and the application layer which contains repository interfaces, sometimes they'll be inside the domain layer itself. The most important thing is to put interfaces close to the code which uses them. I personally like thinking about repositories as being fundamentally no different than any other service used by the application layer. This keeps the "domain" very pure and free from concerns like data persistence. At times, though, data persistence might be so important to the modelling of the domain that it would make sense for it to be at a lower level.
Thanks so much. Excuse me for my ignorance. If I buld a projct with MVVM architecture, am I doing the same concept?. Is a kind of such a relation between Conceptual and Physical.
Well, if significant change is done to the database then no mater which architecture type it is (traditional or an onione one) the change will likely also affect a businnes layer. However, using repository patter to abstract out data from its persistance can signifficantly help (again, no mater archotecture type it is). Thanks for the video!
No fancy RGB background lights, no fancy cuts or animations. Only what's important: Knowledge delivered simply. Appreciate your video very much. Subscribed to get future videos 🙌
Thank you, keep posting videos you have a easy going aura arround you and you ease people with your simple way of speaking!
One of the better explanations out there. Thanks for this
This video should get more views. Very good explanation(the best I could found). Well done. Thanks a lot!
Really good video, i hope you'll continue to make the series (hexagonal, clean)
Thanks for the explanation! This should have more views
Thanks you for sharing. It's very clear and useful for me.👍👍👍
This was a really good overview, especially considering the length. Framing Dependency injection as connecting/swapping similar puzzle pieces is a really intuitive way of expressing the concept. Only so much you can do in 10 minutes, but would have been nice to see more about inversion of control and how modeling software like this allows us to write durable tests for our application layer more easily. Looking forward to seeing what you put out in the future!
Here's another great overview, in 4 mins: czcams.com/video/JubdZIdLQ4M/video.html
Followed by a terrific explanation of Aggregates, Entities, Value Objects and Domain Events: czcams.com/video/xFl-QQZJFTA/video.html
I'm not affiliated, I just found them really helpful
Thanks for the brilliant explanation 🙌🙌
Well done, waiting for more! 👍👍👍
Really nice job! So those puzzle piece holes that you mentioned: are those implemented using interfaces? Would love to see a real code example of how to achieve those holes and how boundaries are achieved (Dependency Inversion?)
Yeah so the hole would be an interface and the puzzle price would be an implementation. I wanted to keep it generic and language-agnostic for this first one but I definitely am planning on doing some much more specific code examples.
@@professionalprogramming8265 Awesome! Looking forward to it 😊
Awesome.. looking to see more videos :))
Thanks bro, concept is clearly explained well.
Excellent video with superb visulazation to explain it in a very simple and elegant way, Thanks a lot. As a side note would you like to share what tech gadget you are using for drawing and displaying those diagrams?
Very nicely done.
thanks, at last some people who knows what they are talking about
Great Explanation !!!!!!!!! really apreciate it
Glad it was helpful!
Thank you, this was great!
What an amazing explanation!!! Thank you so much!! +1 sub
Thank you for the great job, smashing the subscribe button
Great Video! Thank You!
i appreciate your content ,i love this video,thax
Iwould like to know how u make video ,writing on screen and it appears on video in same time ,i like this
Thanks! I'm glad you liked it!
For writing on the screen, I used the Microsoft Whiteboard app with a pretty basic pen input and just layered them together in OBS Studio using a luma key filter to remove the background.
@@professionalprogramming8265 nice job thanks❤️
thank you, really helpful!
That's silly changing the db from say relational to NoSql won't ripple through the stack. Think of any application consuming a third party api that's consuming a database. The Api layer necessarily protects is meant to encapsulate / abstract details from the the client's using it
Nice!!! very good explanation.
Thank you!
Thank you, great explanation
Very helpful, thanks!
Hii, what is the difference between Domain Serveces and Application Serveces in the onion architecture?
The jigsaw puzzle pieces are shown in the application layer, however the repository interfaces (also jigsaw puzzle pieces) are typically defined in the domain layer, so does this mean the domain layer also allows things to be plugged in like the repository implementations. In the diagram above the sql repository implementation is shown plugged into some application service but wouldnt it get plugged directly into the domain layer if the IRepository interface has been defined in that layer
Where to put repository interfaces is open for a bit of a debate. Sometimes you'll see a "Domain Services" layer in-between the domain layer and the application layer which contains repository interfaces, sometimes they'll be inside the domain layer itself. The most important thing is to put interfaces close to the code which uses them. I personally like thinking about repositories as being fundamentally no different than any other service used by the application layer. This keeps the "domain" very pure and free from concerns like data persistence. At times, though, data persistence might be so important to the modelling of the domain that it would make sense for it to be at a lower level.
@@professionalprogramming8265 Thanks agree
Thanks so much. Excuse me for my ignorance. If I buld a projct with MVVM architecture, am I doing the same concept?. Is a kind of such a relation between Conceptual and Physical.
Well, if significant change is done to the database then no mater which architecture type it is (traditional or an onione one) the change will likely also affect a businnes layer.
However, using repository patter to abstract out data from its persistance can signifficantly help (again, no mater archotecture type it is).
Thanks for the video!
Event Sourcing.