@CodeOpinion , I've heard you express that idea before, and I'm glad to be honest. It'll keep you honest. :) But I think you have things worth saying, and I appreciate your channel. There is one thing that I wish you would do, though. I don't see a lot of references in your video descriptions to "upstream" sources. (When applicable.) I think it'd help prevent semantic diffusion if people did that more often.
Agreed. One of my former companies had so strict rules and were so dogmatic that they had to find huge solutions instead of allowing pragmatism for just a tiny part. It's really incredible how much time wasted and money piles up after a while with that
In my opinion the issue still is that you have a bad example and know that it’s bad and maybe even know why it’s bad but what would a less bad approach look like for the particular example. I know that transforming a bad example into a less bad or better approach is nearly impossible because of the lack of context and such. But still, just seeing bad examples and knowing that they are bad and why the are bad leaves me with the question of: how would you have done it instead.
Your format is good. In ten or fifteen minutes you manage to explain things clearly and calmly highlight both the advantages and disadvantages with each approach. LinkedIn “devposts” tend to be click bate designed to make people angry and/or eager to defend their javascript framework until their death.
I don't know of another industry where there's such a gap between what you learn in school (computer science, or some stripped-down version of it) and what you need to know to do your job. I understand why things are the way they are: software is almost infinitely malleable, and the industry is very new. We'll get there eventually, I hope. But in the meanwhile we, in the industry, should be focused (both individually and collectively) on collecting the wisdom and experience of the industry and weaving it into a unified theory of how we should be doing our jobs. Instead, what we have, to a large degree, is what you see on LinkedIn: we DDoS ourselves with "brand building" hot takes. It's a classic case of the Tragedy of the Commons.
Oh, and don't get me wrong: I think we undervalue computer science, but its relationship to software engineering is the same as physics to mechanical engineering: foundational and inadequate at the same time.
There are different computer degrees in college. For building web, mobile, windows apps and working with db's for businesses, "Computer Information Technology" or computer info sys degrees are the closest fit. Computer science is better fit for building OS, working for science and military orgs. More diehard. Beyond my capability. 😅
An academic setting just isn't a good place to learn software engineering. I think something similar to what tradesmen do where you have a few years in trades school then spend time in the industry as an apprentice would be much better
Another great video Derek! Your analysis on the second case was "Sherlock Holmes" level, I couldn't see with my own eyes until you've pointed out the issues, after that it was clear as a sunny day. One idea for your videos over Linkedin, Twitter, Facebook, name your social media post is to make a Reaction series, "Reacting to SWE Hot-takes" or something like that, also theses kinds of videos can render tons of shorts ;D
Quite often people to push and promote unnecessary complexity are flashy middle managers who have little experience writing actual systems and think that complexity automatically mean a better system
I really love the little turd piles concept. That's absolutely the point, isolate specific code and code paths related to specific actions that have the freedom to evolve independently of other specific actions. This in turn reduces coupling between the various unrelated actions. As far as the crud comment. There are many places where data entry type scenarios that happens in software applications this can be crud based activities. I'm thinking of crud as there is very little logic or rules around processing a request (maybe transaction script is more appropriate) Registering for a website and updating your profile might involve crud. Drafting a blog post is crud. Entering product details in an e-commerce scenario is crud. Most of these situations are not operating on or depend on "shared" data. Anyway, great video as always🎉🎉!🎉
That’s a great quote by Alberto Brandolini you shared in the video, I wish I had learned the lesson about the pitfalls of design by entities earlier in my career. Thanks!
Thanks Derek! I liked the format. As always you bring us some clarification about some of these important concepts. I think that the challenge is really the process of discovering the behaviors in a new domain and not knowing if it's right or not. I have a question for you: What do you think its the main source of your knowledge about DDD and Software design in general? Is it from practice, books, articles, papers, or all of it?
Feature slice vs Domain capability. I never liked the first one unless you are building a UI. When I expose a micro-service though an API, this is singled context. No need to separate it in features.
Love your take on this especially when someone thinks that there are doing vertical slicing in which they weren't Your diagram about the dinner reservation really clicked with me on what you are trying to say. How about showing the high level domain vertical slicing diagram for the dinner reservation?
Why are people reading LinkedIn posts for recommended/best practices? Jeesh, it's like FB and news. It's social media. Use it for social stuff, and it's primary purpose of networking for job opportunities, but not as a trusted source for design best practices.
Greg Young has talks about not building a big ball of mud, but instead build small balls of mud. Everything will end being a ball of mud, it is unavoidable. The diiference is, that a small ball of mud is still maintainable, or even better you can just delete it and rewrite in a sprint.
@@CodeOpinion could you do a complex example in that video you are going to create? Something like different modules/microservices, each module with different capabilities, and if those vertical slices use clean architecture… how do they share the domain classes between features of the same module? Where does these domain classes live? Thanks!
based on the title, I was expecting a discussion about whether it's even useful to have technical discussions on LinkedIn - it just seems like entirely the wrong platform for that, for two reasons. (1) many (perhaps even most) of the people who would see your content are going to be non-technical, and therefore (2) the incentives for posting anything technical are all wrong. can you trust anyone posting anything technical on LinkedIn? are they really trying to help, or even have a serious discussion? or are they posting to profile themselves and look interesting to potential employers? these past few years, it's as though LinkedIn wants us to forget what it is - a professional network and hiring platform. now we're supposed to think it's a social media. it never really was, and the only reason they're trying to be, is because "more engagement good" for their investors. there are much more appropriate forums for technical discussions, where your future employer or your manager aren't watching to see if you look "smart". 🤨
The "serious" discussions are few and far between on LinkedIn. While rare, they do occur though. They just likely aren't in a post by "content creator" whos infographics posts garner 1000s of likes. It's often more of the smaller posts and comments can get into some nuance, which is nice. But the mass appeal posts, not so much.
@@CodeOpinion it happens, sure - but would have had more impact on a platform where people actually show up to discuss development. If LinkedIn is appropriate for anything in that vein, it's usually closer to topics like process and management than technical details. In my experience. 🙂
Don't show that emoticon after show adds from a partner. Now, my mind think thst product is garbage. Pay attention about those details. This is not a good emoticon 💩
Here's a good game. The next video I don't mention it explicitly, think about the root cause of what I'm talking about and see if it's coupling. It probably is, I'm not saying it :)
@@CodeOpinion Just started at a new company and honestly can't stop thinking about this. Everything is all about technology this, optimize that, refactor after refactor. But then I'm still like, but what depends on what and why? I wish to some day figure out the idea behind coupling lol
IMO there is too much of everything everywhere today
Agreed and in some ways I'm piling on by posting.
@CodeOpinion , I've heard you express that idea before, and I'm glad to be honest. It'll keep you honest. :) But I think you have things worth saying, and I appreciate your channel.
There is one thing that I wish you would do, though. I don't see a lot of references in your video descriptions to "upstream" sources. (When applicable.) I think it'd help prevent semantic diffusion if people did that more often.
linkedin is exhausting 100 ppl repeating the same things a 100 times, why😭
Agreed. One of my former companies had so strict rules and were so dogmatic that they had to find huge solutions instead of allowing pragmatism for just a tiny part. It's really incredible how much time wasted and money piles up after a while with that
Great format - knowing why something is "wrong", instead of why it's "right", is so much more educationa.
Great suggestion!
In my opinion the issue still is that you have a bad example and know that it’s bad and maybe even know why it’s bad but what would a less bad approach look like for the particular example.
I know that transforming a bad example into a less bad or better approach is nearly impossible because of the lack of context and such. But still, just seeing bad examples and knowing that they are bad and why the are bad leaves me with the question of: how would you have done it instead.
Your format is good. In ten or fifteen minutes you manage to explain things clearly and calmly highlight both the advantages and disadvantages with each approach.
LinkedIn “devposts” tend to be click bate designed to make people angry and/or eager to defend their javascript framework until their death.
Sure are a lot of animated infographics
I don't know of another industry where there's such a gap between what you learn in school (computer science, or some stripped-down version of it) and what you need to know to do your job.
I understand why things are the way they are: software is almost infinitely malleable, and the industry is very new. We'll get there eventually, I hope. But in the meanwhile we, in the industry, should be focused (both individually and collectively) on collecting the wisdom and experience of the industry and weaving it into a unified theory of how we should be doing our jobs.
Instead, what we have, to a large degree, is what you see on LinkedIn: we DDoS ourselves with "brand building" hot takes. It's a classic case of the Tragedy of the Commons.
Oh, and don't get me wrong: I think we undervalue computer science, but its relationship to software engineering is the same as physics to mechanical engineering: foundational and inadequate at the same time.
There are different computer degrees in college. For building web, mobile, windows apps and working with db's for businesses, "Computer Information Technology" or computer info sys degrees are the closest fit. Computer science is better fit for building OS, working for science and military orgs. More diehard. Beyond my capability. 😅
An academic setting just isn't a good place to learn software engineering. I think something similar to what tradesmen do where you have a few years in trades school then spend time in the industry as an apprentice would be much better
Another great video Derek! Your analysis on the second case was "Sherlock Holmes" level, I couldn't see with my own eyes until you've pointed out the issues, after that it was clear as a sunny day.
One idea for your videos over Linkedin, Twitter, Facebook, name your social media post is to make a Reaction series, "Reacting to SWE Hot-takes" or something like that, also theses kinds of videos can render tons of shorts ;D
It's kind of in that reaction category but I just want to provide meaningful dialog to it.
Quite often people to push and promote unnecessary complexity are flashy middle managers who have little experience writing actual systems and think that complexity automatically mean a better system
I really love the little turd piles concept. That's absolutely the point, isolate specific code and code paths related to specific actions that have the freedom to evolve independently of other specific actions. This in turn reduces coupling between the various unrelated actions.
As far as the crud comment. There are many places where data entry type scenarios that happens in software applications this can be crud based activities.
I'm thinking of crud as there is very little logic or rules around processing a request (maybe transaction script is more appropriate)
Registering for a website and updating your profile might involve crud. Drafting a blog post is crud. Entering product details in an e-commerce scenario is crud.
Most of these situations are not operating on or depend on "shared" data.
Anyway, great video as always🎉🎉!🎉
Exactly. I often find CRUD is more reference data instead of transactional is another way of thinking of it.
I like the battenberg cake architecture.
That’s a great quote by Alberto Brandolini you shared in the video, I wish I had learned the lesson about the pitfalls of design by entities earlier in my career. Thanks!
It's wild because I think it's generally the standard way people develop from a data model out.
Thanks Derek! I liked the format. As always you bring us some clarification about some of these important concepts. I think that the challenge is really the process of discovering the behaviors in a new domain and not knowing if it's right or not.
I have a question for you: What do you think its the main source of your knowledge about DDD and Software design in general? Is it from practice, books, articles, papers, or all of it?
Practice. Some things I "understood" but not really until I had an "ah-ha" moment living it.
Awesome content as always Thanks
Feature slice vs Domain capability. I never liked the first one unless you are building a UI.
When I expose a micro-service though an API, this is singled context. No need to separate it in features.
Love your take on this especially when someone thinks that there are doing vertical slicing in which they weren't Your diagram about the dinner reservation really clicked with me on what you are trying to say. How about showing the high level domain vertical slicing diagram for the dinner reservation?
Good suggestion, I'll get that in my topic list!
This Week in Software Architecture
Let's rebrand VSA to Micro-Turd-Piles MTP
Why are people reading LinkedIn posts for recommended/best practices? Jeesh, it's like FB and news. It's social media. Use it for social stuff, and it's primary purpose of networking for job opportunities, but not as a trusted source for design best practices.
No idea, but it must be working because there's a ton of them and some have thousands of likes and comments.
Do you have any course that walks through the domain driven system design (and also includes other important concepts)?
I do not at the moment.
@@CodeOpinion looking forward to when it will be out :)
Greg Young has talks about not building a big ball of mud, but instead build small balls of mud. Everything will end being a ball of mud, it is unavoidable. The diiference is, that a small ball of mud is still maintainable, or even better you can just delete it and rewrite in a sprint.
I prefer to call them turd piles :)
Derek roasting himself
Thank you so much for this.
awesome video
Glad you enjoyed it
LinkedIn Lab: Dissecting Design Posts
not bad!
Vertical slice + Event Modeling can be great
What is event modeling
This video is missing closure. What would the folders/projects looked like in your workflow example
Good feedback, I'll create another video around this.
And where do you couple? Database Level? On an ID? How do you handle cross cutting concerns like authorization?
@@CodeOpinion could you do a complex example in that video you are going to create? Something like different modules/microservices, each module with different capabilities, and if those vertical slices use clean architecture… how do they share the domain classes between features of the same module? Where does these domain classes live? Thanks!
There's a website specifically for bad software takes?! I've been using TH-cam wrong all this time 😮
it depend , lots of budget - counter bad code , low budget - prolong good code no use also .
Maybe... code cop?
I was thinking about writing this answer 😂
I was thinking about something along those lines but I think someone is using that already.
based on the title, I was expecting a discussion about whether it's even useful to have technical discussions on LinkedIn - it just seems like entirely the wrong platform for that, for two reasons. (1) many (perhaps even most) of the people who would see your content are going to be non-technical, and therefore (2) the incentives for posting anything technical are all wrong. can you trust anyone posting anything technical on LinkedIn? are they really trying to help, or even have a serious discussion? or are they posting to profile themselves and look interesting to potential employers? these past few years, it's as though LinkedIn wants us to forget what it is - a professional network and hiring platform. now we're supposed to think it's a social media. it never really was, and the only reason they're trying to be, is because "more engagement good" for their investors. there are much more appropriate forums for technical discussions, where your future employer or your manager aren't watching to see if you look "smart". 🤨
The "serious" discussions are few and far between on LinkedIn. While rare, they do occur though. They just likely aren't in a post by "content creator" whos infographics posts garner 1000s of likes. It's often more of the smaller posts and comments can get into some nuance, which is nice. But the mass appeal posts, not so much.
@@CodeOpinion it happens, sure - but would have had more impact on a platform where people actually show up to discuss development. If LinkedIn is appropriate for anything in that vein, it's usually closer to topics like process and management than technical details. In my experience. 🙂
always good videos
Glad you like them!
Don't show that emoticon after show adds from a partner. Now, my mind think thst product is garbage. Pay attention about those details. This is not a good emoticon 💩
God, I hate LinkedIn
You're not the only one
There is so much trash on LinkedIn
Call it LinkedOut
ha! good suggestion
Every video is about coupling :D
Here's a good game. The next video I don't mention it explicitly, think about the root cause of what I'm talking about and see if it's coupling. It probably is, I'm not saying it :)
@@CodeOpinion Just started at a new company and honestly can't stop thinking about this. Everything is all about technology this, optimize that, refactor after refactor. But then I'm still like, but what depends on what and why? I wish to some day figure out the idea behind coupling lol