Domain-Driven Design Made Me Realize Something About AI Tools
ฝัง
- เผยแพร่เมื่อ 7 ก.ค. 2024
- In this video, I explore domain-driven design from a philosophical angle, sharing surprising insights I've gained. It's a bit different from my usual content, but I think you'll find it interesting. Let me know what you think in the comments!
👷 Join the FREE Code Diagnosis Workshop to help you review code more effectively using my 3-Factor Diagnosis Framework: www.arjancodes.com/diagnosis
💻 ArjanCodes Blog: www.arjancodes.com/blog
✍🏻 Take a quiz on this topic: www.learntail.com/quiz/egudlw
Try Learntail for FREE ➡️ www.learntail.com/
🎓 Courses:
The Software Designer Mindset: www.arjancodes.com/mindset
The Software Architect Mindset: Pre-register now! www.arjancodes.com/architect
Next Level Python: Become a Python Expert: www.arjancodes.com/next-level...
The 30-Day Design Challenge: www.arjancodes.com/30ddc
🛒 GEAR & RECOMMENDED BOOKS: kit.co/arjancodes.
👍 If you enjoyed this content, give this video a like. If you want to watch more of my upcoming videos, consider subscribing to my channel!
Social channels:
💬 Discord: discord.arjan.codes
🐦Twitter: / arjancodes
🌍LinkedIn: / arjancodes
🕵Facebook: / arjancodes
📱Instagram: / arjancodes
♪ Tiktok: / arjancodes
👀 Code reviewers:
- Yoriz
- Ryan Laursen
- Dale Hagglund
- Kit Hygh
- Alexander Milden
- Bean
🎥 Video edited by Mark Bacskai: / bacskaimark
🔖 Chapters:
0:00 Intro
0:45 Understanding Domain-Driven Design
2:18 Couple model and implementation
3:50 Cultivate a language based on the model
5:43 Develop a knowledge-rich model
6:46 Distilling the model
7:40 Brainstorm and experiment
9:17 Domain model vs code
13:25 Final thoughts
#arjancodes #softwaredesign #python
DISCLAIMER - The links in this description might be affiliate links. If you purchase a product or service through one of those links, I may receive a small commission. There is no additional charge to you. Thanks for supporting my channel so I can continue to provide you with free content each week!
👷 Join the FREE Code Diagnosis Workshop to help you review code more effectively using my 3-Factor Diagnosis Framework: www.arjancodes.com/diagnosis
This book was actually very helpful to me. I worked on a chemical process control system ~7 years ago, and I decided to follow the DDD philsophy, because it felt like a natural fit to what I was working on. It turns out that the software came out remarkably robust, and the code is almost self-documenting. The price I had to pay was that I had all sorts of little Value Object classes, as well as the other DDD infrastructure, which made the codebase that much denser. I do feel, however, that this was a small price to pay when compared to what came out! I'd also recommend the book "Implementing Domain Driven Design" by Vaughn Vernon, in case anyone's interested in a more "hands-on" type of book.
Probably the single biggest influence on my career since I was first introduced to it in 2002. I've since had a hand in building robust and long-lived systems at every company I've worked for since. Robust and long-lived because by recognizing real world ontological meaning and adopting precise semantics means that your solutions can only evolve subject to real-world constraints rather than merely software artifacts, which leads to brittleness.
Excellent video. More of this, please. As someone who is a business analyst who occasionally codes rather than a professional developer, the idea of developing and expressing a domain model is core to the way I feel software development should be done. Gherkin (for BDD) as a way to express detailed requirements in non-technical language is a step in the right direction, but I wonder whether there's some sort of "domain-driven design" expression language that can bridge the gap between project sponsors and developers. If not, we need one.
That’s called ATDD
You might be interested in Event Storming by Alberto Brandolini. It is a communication technique to find the domain of a problem, and its boundaries.
@@Naej7, from what I read, ATDD is just another name for BDD. In your experience do they differ? If so, how?
@@jdray Different name = different stuff, it’s as simple as that. You can do BDD without test, but if you do BDD by writing tests first (one at a time), then it’s ATDD
I recently found your channel and have fallen in love with your teaching style. I'm a self-taught machine learning researcher (physicist by training) and have felt pretty insecure about my software development skills. You are really helping me to level up and enjoy the process - thank you!
This video really hit the spot. Machine learning at its core is representation learning - ML models learn representations of domains such that they can accurately represent the relationships between data within that domain. In that sense, as an ML Engineer I am the meta-domain model learner :D I learn the domain within which the domain learner operates. It's a fractal ecosystem of learning! ... I need to go to bed lol
I loved the video, these discussions are needed more often. One can forget sometimes that the tools we build are for other humans and as such they need to satisfy a requirement instead of focusing on picking the right tool (which is important, but not the most important in the exploration/experimentation fase)
@ArjanCodes I recently came the same realization recently, when I was building an api that is integrated with LLM, domain driven design coupled with event driven patterns such as CQRS and event sourcing is the foundation for advance RAG and monitoring for that fast feedback loop.. I am currently exploring this.. we are aligned so far
I regularly work with DDD concepts to build and release software for my clients. This is a great video and touches on topics key to building great software. Too often, people try to over complicate what is essentially "how we are going to logically bound our work" and fail to realize the value in strong communications. Thank you for the video!
Glad you enjoyed the content!
This reminds me of the Top Down vs Bottom Up strategies. Very important reminder that the top down viewpoint starts this far outside of the code itself.
Awesome video! Thank you so much. A minor thing that would have made me enjoy it even more -- I found how loud the music was to be a little distracting in the intro section, no idea if that's just a me thing, but yet again you present really interesting and complex concepts in a clear and compelling way!
I really like your broad approach on software development ! Finally doing some sort of abstraction away from the pure programming will help to improve the communication to your customer. So: Thank you for that ! Saying that: Sometimes I struggle with some idea I implemented as a "proof of concept" which then evolves over time. And at a certain point in time I wish I had done some more abstract reserach like you described it in here (domain model). But that's something which might not happen that hard in the future - assuming an inclining learning curve ... 😉
You should also read "The Lean Startup" by Eric Ries if you haven't already. It presents similar ideas but from the perspective of building a business. It's all about failing early and iterating quickly to understand the shape of the Domain Model you're working on.
Absolutely! The Lean Startup was one of the first business books I read, together with The E-Myth Revisited by Michael Gerber, which is also a great book by the way.
@@ArjanCodes I haven't read the The E-Myth Revisited. I will check it out. Thanks for the recommendation.
The book "Zero to One: Notes on Startups, or How to Build the Future" by Peter Thiel may be useful.
Your point about how we worry about the details of the code is what I think about most when pontificating on AI. While I don't trust OpenAI to create my code for me, I love how much easier it is using Github Copilot. Adding log commands, doc strings, etc. don't interrupt my flow. It handles the part of programming that has always just been out of reach of automating away. Thus, I'm freed up to focus on the big picture.
I would like to see a FastAPI & SQLAlchemy project implementation according to DDD design principles.
Thank you @ArjanCodes , this , by chance helped me get a hold on what I needed to focus on my system design. More specifically what would add value when deciding on a software development methodology.
Hey Marius! I'm very glad that this video was helpful to you, thank you for the comment :)
I work in the safety-critical embedded world, which means I use C for the project and Python for the tools. Most programmers can make a C program that works, but few can write it in a way that is (1) easy for the reader to understand and (2) hard to mis-use. As I learn Nim, I'm finding that Nim's cleaner and more expressive syntax and strong static typing are exactly what is needed to craft code that meets those two criteria. My next step in learning is figuring out how to arrange a project or library in a way that screams its design. So the DDD book is on my TODO list.
This video is a game changer. I am able to view code in a different way and i am going to iterate more on the DDD journey to make me better at idea realization and code optimization
I'm glad the video was helpful to you!
Good recommendation! Thanks Arjan.
Glad the video was useful to you!
I've been hoping you'd do a series on Domain-Driven Design for a long time! I'm working through the book myself at the moment and it is dense, so I would love to hear your thoughts and breakdowns of relevant concepts.
I'm glad you enjoyed the video! Thank you for the kind words :)
14:38 I think Domain model better our understanding of what and to whom and why we build something we build. Code is how we build it. I think the view code is an expression of domain model is very apt. It also nicely give a reason to follow agile and early prototyping process. If code is an expression then design patterns is the grammer of writing it. Overall a fantastic summarisation. Thank you
I'm glad you enjoyed the content! Thank you for the insightful comment :)
Great timing. My dad is a software dev and just last week I found this book in his library.
Hope this video incentivizes you to give it a read!
Google knows!
In the UK we say my-NYOO-sha. God only knows how the Americans pronounce it.
I don't use AI to write or help with any of my code as I want to maintain the muscle memory, but I increasingly use it to get up to speed with a new domain. In consulting we used to try to trawl through thousands of mostly irrelevant client documents and try to pick out key concepts to clarify with the client's domain experts. But they were often only available once and going back to them again looked a bit unprofessional, especially if the answer you were looking for was in the documentation.
I still believe in reading a good book on a domain when you have the time, but since that happens almost never, AI is a great tool to get the essentials so you can ask smart questions of the experts. And the best part is that it takes all the pressure off the initial discovery period, as you can go back to the LLM and clarify details at any time!
Thanks for the video, I'm gonna look more into this DDD thing, using AI before I decide if I want to read that thick book 😂
Familiarity with the customer domain is a critical success factor for a software project. It is the job of the Architect / Product Owner to explain the various concepts to all programmers working on the project so that they all get an understanding for them. This will help them interpret stories, design tests, and design the structure and functionality of the software. Without that understanding, there will be loads of booboo moments where they misinterpret what the customer wants.
it would be amazing to see a practical example of this technique from "idea" to "product"
Thanks Arjan, loved this, if only this approach was used more, there would be so many great examples of code that actually serves it purpose!
Glad you enjoyed it, Kevin!
Eric Evans had a discussion about a similar topic on Dave Farley’s channel not too long ago
Very nice concise explanation of DDD. (And I love the term "trashcan-oriented design"!)
Thank you, Eric! Glad you enjoyed the video.
Great content as usual
Thank you so much for the support!
Super interesting. I'm unsure the domain model seems to be what "is", but I agree one must capture it accuratel
Maybe it's just all data maybe it's all just functions 😊😅
Teacher. It's excelent.
you rock, thanks man!
Happy to help!
After a while I could only focus on the water glass.
Great video though, on an important topic.
is there any good course explaining DDD to learn and apply it on daily basis? or any workshop/talk?
10:00 so True
Thanks for the video and the insights.
I totally agree with the assumption that DDD is the main thing for AI programming.
Glad you found the video useful!
With general development with domain models, AI will effect areas where developers are happy to use AI. There are a number of factors why AI might not be able to be used (nobody bothering - embedded low-level code, too small userbase, too small code base for LLM, future or current legislation in the domain)
Rust gang! I wrote a linked list in Rust and I felt like PhD when I got it to work😂
Now do doubly linked
I didn't read the book yet, but i wanted to express a feeling i am having lately that I think is very in line with what Arjan says about new AI tools and devs relationship.
It turns out that i find myself more and more working in the model (whether is a domain or business or ER model it doesn't really care) of my solution and the architecture or the UI than in code itself, for which i use IAs extensively by now.
Last couple of projects I spend 2 of 3 months working in the traditional modeling and test planning, and actually spend less than 1 month in the actual coding/implementation... Is that good? is that bad ? I like the usual design process and i am happy with that but I understand there could be other approaches/preferences.
Is a weird feeling for me... because i used to use about a 50% or more in coding than actual designing phase... either that be because Agile prone for rapid cycle times and frequent iterations or the itching eagerness of the usual project manager (or manager) I don't know, honestly.
Thanks for the insights Arjan, it's great pleasure to learn something new with you every week.
I'm happy my content helped you think deeper about these topics! Thank you so much for the insightful comment :)
You got me laughing with Trashcan-oriented Programming. Acronym would be ToP
I’ve come to think of software as not much more than the front end of a database. You say domain, I say schema. When I think of AI’s role in programming, I think of it as another layer of abstraction. Back when programmers used Assembly, there were few programmers. With each level of abstraction, programming became easier and allowed more people to be programmers. I couldn’t program against LLM’s if it weren’t for all of the OS frameworks and libraries, not to mention the ease of high level languages like Python which today, are all freely available. I think that with AI, more people will consider themselves programmers. AI won’t replace programmers, it will create far more new programmers.
A database schema and a domain model are certainly not analogous. If they were, that would imply a database schema can have behaviours which, of course, they do not. The way state/data is persisted is an implementation detail and a secondary concern following a rich domain model.
The obvious conclusion is that the domain design will eventually look like a prompt that defines the ubiquitous language and then describes the domain using that language. I want to know where to go to learn more about that. Who is doing that? What patterns are relevant to that way of developing?
Trash Can Oriented Programming ( TCOP ) :) Brillient
Glad you enjoyed it! Ahah
Zonder recept kan je niet een goed gerecht maken, tenzij een genie bent. Good video! Go on!
I don't think trying to learn from a divorced emerald mine inheritor who failed upwards and is in the process of tanking twitter is the best idea
A good idea is still a good idea, regardless of who Elon probably stole it from.
Min-yoo-shuh 🙂
Trashcan oriented programming, what a summary 😅 for real though, very interesting video, keep it up!
Thank you, will do!
What is up with the glass of water?
He must have read an article suggesting the use of a prop like that. It was distracting though. I kept expecting him to throw the water at the camera!
Man can’t drink ?
Am I arrogant to think that that's the common sense way off doing things and not really a methodology per se
Do not agree at all, it's going be long debate do not prefer to step into......
Some constructive criticism; maybe don't include tips from an alt-right fascist in your otherwise non-emotive video - it left me with a bad taste in my mouth, and that's kinda distracting when you just want to learn stuff..
New subscriber here. Thanks for talking about these topics. P.S. you sound very similar to another channel I follow: @mentourpilot