Hey great video! Really enjoyed hearing your thoughts on things mentioned in my video. I definitely agree people try to force DDD because it's what they have been told. I did want to clarify the "I've done DDD and it was too complicated and didnt work". I didnt include this in my video but the project where we used DDD was a large project with well over 150 endpoints and was more of an RPC API since each endpoint was pretty much an individual business rule. The domain for the project was handling the government regulations around greenhouse gas emissions calculating and reporting to the Australian government, so definitely not just simple CRUD. Once we ripped out DDD and went to using a more procedural approach with the endpoints and just letting data be data, the code was much simpler
This could be a dumb question, but when devs, like yourself our facing this massive 150 endpoints type of problem why not take a step back ask the question “Is it time to switch to GraphQL?”
This is a really great video, I like how it showcases the pros of the simple app structure and I like even more how it demonstrates options and use cases for a progressive enhancement. Great job, thank you!
I love this, start simple and add complexity. If you start with a complex solution and it fails, it's really hard to figure out what went wrong or where it fell short.
I generally like this idea, but the problem I have is that all of these videos always use very simple projects. Try this with an application that has millions of lines of code.
His example is a very simple, data centric approach. In practice, I've never worked on any application that does nothing but CRUD through an API. There's more business logic that has to go somewhere. If he added a presentation layer to that simplistic API, it would become obvious that it's not up to task.
I watched the video from the other guy when he released it and I couldn't finish it (I disagreed too much). Those types of videos work well for beginners but ultimately sends them down a path of confusion. Senior devs understand that the architecture evolves with the project and "it depends" is usually the right answer to what type of architecture they should use or recommend.
How can you disagree with a particular approach in a vacuum, yet recognize in a following sentence that these decisions depend on the problem context? I would say the opposite is true, smaller code bases, with minimal abstractions are in general easier to navigate and make sense of.
Great video! But one thing that I didn't quite understand was the handling of DTOs. In the video he just adds them as Request and Response classes to the specific endpoint. But what if your domain models are way bigger and your endpoints duplicate those (like your create and update endpoint)? Wouldn't it make more sense to have a general PostDto, CommentDto, etc? He probably didn't do this because his features were simple still.
Talking about VSA, what can we say is a feature? Is it a specific method that users have available (for example, to like a post)? Is it a DDD domain or subdomain? Is it an aggregate? I know "it depends," but still, what could be an initial approach or heuristic to create those features?
My thoughts on this topic: As always, there's simply no "one size fits all". Each and every software has its own requirements, architecture, and therefore its own project structure. You can have blueprints or templates as starting point, for sure, but don't let them dictate everything. Adhere to common principles like simplicity, consistency, readability, maintainability-they should be more valuable than any prescriptive structure.
Well ... none of the approaches take into consideration the broader context. For example, if you need speed of initial development but not so much maintenance, slicing you entire project vertically makes far more sense. If your app is planned for an extended lifespan you go for the DDD structure. And there are also in-betweens. If you get more changes along the lines of: "user profile needs these additional attributes", then it make sense to have all the changes limited to the userProfile folder. Hell, after a while you can slowly reform the structures to the changes you are getting along the lifespan of your app and have all of it requiring the change of a single file. Another example would be: "we are changing the service that provides the todo list because cloudflare lied again". Initially you'll have that in the todoList folder, but lets say, it happens at a high frequency and other services change aswell. Then you may need to break away the logic handling calls to services and their transformation into a separate folder and create a new vertical dimension. Personally, fully decoupled DDD is my favourite. One of the basic tests I do is deleting a 'D folder. The app should still compile and run flawlessly without any other change (minus the features provided by the deleted bounded context). Needless to say, i don't believe at all in the "do not repeat yourself" principle outside of the "common" folder.
Great video and article and was wondering if an fellow up post on your excellent points at the end: "... This is where you might want to consider applying other types of patterns so you can encapsulate all the required behavior when a post is Liked rather than just pure data models and a transaction script as it originally started." What would be some of those patterns in order to avoid the data inconsistency issues?
It all starts with the question of what is defined as complexity. Is it the complexity of familiarizing yourself as a new, inexperienced developer with established structures and frameworks and understanding their principles and abstractions? Ok, that's not easy. But it makes me faster, more consistent and more productive later on. And then it's even easier to always follow the same consistent approach, even for simple parts of the company software, which also works for the more complex problems.
That clean architecture (CA) sample he showed... Was not clean architecture. One of the key components of CA is screaming architecture, which means... Grouping by features. Only when you do that you can then use the rest of CA. How does everyone miss that chapter in the book? 😢
@CodeOpinion I rewatched your video and the original. The thing the turned me off was his suggested folder structure which it seems he didn't fully use in the sample. When I saw "common", "services" , and "data" it immediately made me think there are shared/coupled things here, this could lead to problems in the future. In the Endpoint example he went out of the way to make specific request/response classed but failed to do that in those other scenarios. That frankly was slightly disappointing. I know it feels like EF have has a gravitational pull and it's hard to have more than one context and it kind of forces people down that path and why I try to avoid using it, and common things tend to evolve into specific things that end up breaking things that depend on them. Otherwise, I did like the simple design, and as always appreciated your perspective and insights.
I wonder if there's an ever simpler, better way? I've created a few plugins (well, only 2) for my code editor and the pattern and project structure that I applied there makes me wonder if I should apply them in my professional backend projects too. The idea revolves around user discoverability: 1. The outer layer of the project exposes the external surface of the program, i.e. the APIs and the main executable. 'Clutters' like git and docker files are unavoidable, but it's okay for me (after a while your eyes will be trained to ignore those things). 2. Going 1 layer deeper (a service directory) is about serving each of the exposed APIs, 1 directory per exposed API. If the entire program is simple (like most of my stuff turned out to be), opt for collapsing the directories into 1, separating concerns into files with meaningful names in the same directory. Shared functions will be put in one 'common' level 1 directory. 3. The layer 2 directory concerns itself with dependencies (same as "infrastructures" in the Clean architecture, but decentralized). IMO it's more meaningful for project watchers and maintainers to see this last; the pub-sub, cache, and database files are in the same directory per level 1 directory. Shared functions in this level across different level 1 directories should be in itself an imported dependency. Creating the 'utils' directory for all shared dependency functions in the level 1 'common' directory is acceptable too. 4. No level 3+ directories. Nested directories and small files are the enemy of code comprehension (I see you, Java devs). Naming conventions and other language idiomatics can only help so much.
I am not fan of this approach. I think it is more a trend just came with minimal APIs. There are 2 reasons i don't like this: 1) You mix different areas (models, validations, mapping, endpoints etc) in one class 2) Having a separate class per endpoint "GetByA,B,C,D..." can easily make your project spaghetti and complex for no reason.
More or less: 1 - You don't mix things. You aggregate by feature instead of technical concerns (not all features are endpoints or require mapping, for example). 2 - Quite the opposite. Sometimes is far more complex to have to navigate through multiple classes to perform simple actions.
User type and puts a tape of both are in the same folder that's not ddD, obviously, The two do not belong the same bounder context. No bundled that the in the structure.
I recently started looking into functional programming, where we only have immutable data and functions. According to object-oriented programming (OOP), this is essentially an anemic model. Given that the anemic model is considered an anti-pattern, does this mean that functional programming is an anti-pattern for implementing Domain-Driven Design (DDD)? Or is it considered an anti-pattern only within the context of OOP? Sorry if this question might sound stupid, but with all this terminology and anti patterns it becomes confusing .
As mentioned, I don't think its an anti-pattern at all. I think what makes it an antipattern in on context of OOP is when you *think* you have a rich domain model encapsulating behavior and in reality is you don't.
It's not a stupid question. In FP, any function that would mutate the aggregate would return the new state of the aggregate. The original aggregate would remain untouched. I hope that makes sense to you?
Don't agree. That Like() method on the Post doesn't scale in terms of development. The Post class enforces consistency, but also introduces strong coupling. With increasing number of requirements, the post class will become a bottleneck. Imagine we want to react to posts, report a post, share a post, upvote/downvote a post etc. You'll keep adding those methods and counts to that Post class? Probably, you'll have a different stakeholder for each of those features, so now every time there is a change or a bug in one of those requirements, you'll need to touch the class which might affect other features as well. The transaction script approach will stay simple. New feature for a post is just a new transaction script, a change or a bug in that feature affects only that code.
Everything works fine when it is pretty clear and simple with few line of code. But when it gets super complex people got stuck and that’s approach not working in real life scenarios!
5 years of "experience" here.... I don't think i understand what they both are talking about. Although i watched a lot of architecture videos(Ardalis, CodeOpinion). I have practiced all this on my own, but still can't get really into it :(. I really admire Derek videos, as i see him as great professional. But the videos i watch, almost every time leaves more questions than answers. As the videos are short with already existing logic, and even pauses don't really help. I wish i could get into what Derek says quickly. There is Tim Corey, who explains things really slow and in understandable manner. But he covers only beginner stuff without diving into architecture subject.
Microsoft has their shop on the web examples. Some of them are deprecated but they have made 'books'/pdf that go over the architecture principles in them. One of them is made by Steve 'ardalis' smith. They use Azure but just substitute that for any generic service.
Simple is always best. One problem though is that one person's definition of simple is not always the same as another person's definition of simple. Thus why there are so many different architecture styles and ways to organize the code.
But this is basically REPR design pattern by ardalis? (I'm not in C# so may miss the difference, but the Endpoint idea is pretty much there?) Afterwards you incrementally add layers as required
we start 2000 , the change way much . most become not creative and sometimes become weird , you must follow of this or totally wrong . the worst interface just for unit test ? what happen ?😢
🎯 Key Takeaways for quick navigation: 00:00 *🏗️ Structuring HTTP API Projects* - Different folder structures for organizing HTTP API projects. - Common approaches include organizing by technical concerns, clean architecture, domain-driven design (DDD) with vertical slice architecture. - Templates often lack indicators of actual DDD implementation. 01:24 *🗂️ Adopting a Simpler Approach* - Emphasizing simplicity in project structure over strict adherence to domain-driven design (DDD) patterns. - Advocating for vertical slice architecture for grouping features. - Introducing an endpoints file for a clear overview of API surface. 02:21 *📁 Folder Structure Overview* - Overview of the proposed folder structure: endpoints, common, feature, data. - Explanation of the purpose of each folder in the structure. - Focus on simplicity and ease of navigation. 03:32 *🔄 Endpoint Structure and Contracts* - Explanation of endpoint structure: mapping, request and response contracts, logic. - Importance of defining clear request and response contracts for each endpoint. - Simplifying endpoint handling using static methods in minimal APIs. 07:15 *🧩 Handling Complexity Over Time* - Discussion on managing complexity as projects evolve. - Example of handling denormalized data and maintaining consistency. - Evolution from simple transaction scripts to more complex patterns like repository pattern and event-driven architecture. 09:23 *🛠️ Balancing Simplicity and Complexity* - Balancing simplicity with the need for more complex patterns as projects scale. - Highlighting the importance of understanding coupling and applying solutions judiciously. - Emphasizing the iterative nature of architectural decisions based on evolving project requirements. Made with HARPA AI
Do not kill all those dreams, let them make DDD just creating some folders. Why someone will want to make things complicated adding things like ubiquitous language, a domain expert and all that stuff... let the data be transformed as is it to DTOs.
Use a DB Trigger on the Likes table which increments on insert and decrements on delete. Done. Don't know why you want to put this into your application code
Absolutely a solution (trigger). I was making up an example to illustrate consistency concerns, don't take it all to literally on solution to a made up problem.
All weird stuff begins with such a small pieces of logic spread through different system's layers. This a sooo cool journey to find where the problem is, starting with the presentation layer and going down the road to the db trigger.
Dude what you’re talking about ??? You are one of the problems here. Always overengineering everything !!!! I just want to f build a simple api dude Hahaha
Hey great video! Really enjoyed hearing your thoughts on things mentioned in my video. I definitely agree people try to force DDD because it's what they have been told.
I did want to clarify the "I've done DDD and it was too complicated and didnt work". I didnt include this in my video but the project where we used DDD was a large project with well over 150 endpoints and was more of an RPC API since each endpoint was pretty much an individual business rule. The domain for the project was handling the government regulations around greenhouse gas emissions calculating and reporting to the Australian government, so definitely not just simple CRUD. Once we ripped out DDD and went to using a more procedural approach with the endpoints and just letting data be data, the code was much simpler
"ripped out DDD" or ripped out DDD tactical design patterns?
That's a huge difference and it was one of the most important points of this video.
@@piotrkowalski3460 exactly. DDD != using tactical elements of DDD.
Totally agree! I have great dev experience because of this in current company. I feel many companies overcomplicate things which should be simple
This could be a dumb question, but when devs, like yourself our facing this massive 150 endpoints type of problem why not take a step back ask the question “Is it time to switch to GraphQL?”
Distributed "architecture review" is such a fun format
This is a really great video, I like how it showcases the pros of the simple app structure and I like even more how it demonstrates options and use cases for a progressive enhancement. Great job, thank you!
Glad you enjoyed it!
I love this, start simple and add complexity. If you start with a complex solution and it fails, it's really hard to figure out what went wrong or where it fell short.
Really great and deep understanding of things, really appreciated.
I generally like this idea, but the problem I have is that all of these videos always use very simple projects. Try this with an application that has millions of lines of code.
His example is a very simple, data centric approach. In practice, I've never worked on any application that does nothing but CRUD through an API. There's more business logic that has to go somewhere. If he added a presentation layer to that simplistic API, it would become obvious that it's not up to task.
I just love all your videos Derek.. Wish to have in my team persons like you. Already learned a lot from your channel!
The only word - Great! Much appreciated!
I watched the video from the other guy when he released it and I couldn't finish it (I disagreed too much). Those types of videos work well for beginners but ultimately sends them down a path of confusion. Senior devs understand that the architecture evolves with the project and "it depends" is usually the right answer to what type of architecture they should use or recommend.
Simple solutions to simple problems. Complexity adds up so will the solutions.
How can you disagree with a particular approach in a vacuum, yet recognize in a following sentence that these decisions depend on the problem context? I would say the opposite is true, smaller code bases, with minimal abstractions are in general easier to navigate and make sense of.
Same.
Great video! But one thing that I didn't quite understand was the handling of DTOs.
In the video he just adds them as Request and Response classes to the specific endpoint. But what if your domain models are way bigger and your endpoints duplicate those (like your create and update endpoint)?
Wouldn't it make more sense to have a general PostDto, CommentDto, etc? He probably didn't do this because his features were simple still.
Thanks a lot for a great video with the essential wisdom 👍
Hm, then there's versioning concerns. Wonder what that project structure would look like?
Talking about VSA, what can we say is a feature? Is it a specific method that users have available (for example, to like a post)? Is it a DDD domain or subdomain? Is it an aggregate? I know "it depends," but still, what could be an initial approach or heuristic to create those features?
One suggestion I like is creating features around bounded contexts.
A feature is something that, from the user's point of view.
My thoughts on this topic: As always, there's simply no "one size fits all". Each and every software has its own requirements, architecture, and therefore its own project structure. You can have blueprints or templates as starting point, for sure, but don't let them dictate everything. Adhere to common principles like simplicity, consistency, readability, maintainability-they should be more valuable than any prescriptive structure.
Well ... none of the approaches take into consideration the broader context. For example, if you need speed of initial development but not so much maintenance, slicing you entire project vertically makes far more sense. If your app is planned for an extended lifespan you go for the DDD structure. And there are also in-betweens.
If you get more changes along the lines of: "user profile needs these additional attributes", then it make sense to have all the changes limited to the userProfile folder. Hell, after a while you can slowly reform the structures to the changes you are getting along the lifespan of your app and have all of it requiring the change of a single file.
Another example would be: "we are changing the service that provides the todo list because cloudflare lied again". Initially you'll have that in the todoList folder, but lets say, it happens at a high frequency and other services change aswell. Then you may need to break away the logic handling calls to services and their transformation into a separate folder and create a new vertical dimension.
Personally, fully decoupled DDD is my favourite. One of the basic tests I do is deleting a 'D folder. The app should still compile and run flawlessly without any other change (minus the features provided by the deleted bounded context). Needless to say, i don't believe at all in the "do not repeat yourself" principle outside of the "common" folder.
Great video and article and was wondering if an fellow up post on your excellent points at the end:
"... This is where you might want to consider applying other types of patterns so you can encapsulate all the required behavior when a post is Liked rather than just pure data models and a transaction script as it originally started."
What would be some of those patterns in order to avoid the data inconsistency issues?
I have a bunch of videos that kinda of explain it a bit more, here's one ua-cam.com/video/FbYcIqVmGRk/v-deo.html
It all starts with the question of what is defined as complexity. Is it the complexity of familiarizing yourself as a new, inexperienced developer with established structures and frameworks and understanding their principles and abstractions? Ok, that's not easy. But it makes me faster, more consistent and more productive later on. And then it's even easier to always follow the same consistent approach, even for simple parts of the company software, which also works for the more complex problems.
That clean architecture (CA) sample he showed... Was not clean architecture. One of the key components of CA is screaming architecture, which means... Grouping by features. Only when you do that you can then use the rest of CA. How does everyone miss that chapter in the book? 😢
Just a few seconds in, I saw the video in question a few days ago and he had me for a few minutes then lost me when he made recommendations
What specifically about the recommendations?
@CodeOpinion I rewatched your video and the original. The thing the turned me off was his suggested folder structure which it seems he didn't fully use in the sample. When I saw "common", "services" , and "data" it immediately made me think there are shared/coupled things here, this could lead to problems in the future. In the Endpoint example he went out of the way to make specific request/response classed but failed to do that in those other scenarios. That frankly was slightly disappointing. I know it feels like EF have has a gravitational pull and it's hard to have more than one context and it kind of forces people down that path and why I try to avoid using it, and common things tend to evolve into specific things that end up breaking things that depend on them. Otherwise, I did like the simple design, and as always appreciated your perspective and insights.
How do you prevent your team from adding db calls directly from endpoints in a single project structure?
I wonder if there's an ever simpler, better way?
I've created a few plugins (well, only 2) for my code editor and the pattern and project structure that I applied there makes me wonder if I should apply them in my professional backend projects too.
The idea revolves around user discoverability:
1. The outer layer of the project exposes the external surface of the program, i.e. the APIs and the main executable. 'Clutters' like git and docker files are unavoidable, but it's okay for me (after a while your eyes will be trained to ignore those things).
2. Going 1 layer deeper (a service directory) is about serving each of the exposed APIs, 1 directory per exposed API. If the entire program is simple (like most of my stuff turned out to be), opt for collapsing the directories into 1, separating concerns into files with meaningful names in the same directory. Shared functions will be put in one 'common' level 1 directory.
3. The layer 2 directory concerns itself with dependencies (same as "infrastructures" in the Clean architecture, but decentralized). IMO it's more meaningful for project watchers and maintainers to see this last; the pub-sub, cache, and database files are in the same directory per level 1 directory. Shared functions in this level across different level 1 directories should be in itself an imported dependency. Creating the 'utils' directory for all shared dependency functions in the level 1 'common' directory is acceptable too.
4. No level 3+ directories.
Nested directories and small files are the enemy of code comprehension (I see you, Java devs). Naming conventions and other language idiomatics can only help so much.
you always may use minimal api with a single program.cs file for a simple rest api application
@@timur2887 yeah but that doesn't scale. My "simple" plugin is already ~10 kLoC long and it's still WIP.
I am not fan of this approach. I think it is more a trend just came with minimal APIs. There are 2 reasons i don't like this:
1) You mix different areas (models, validations, mapping, endpoints etc) in one class
2) Having a separate class per endpoint "GetByA,B,C,D..." can easily make your project spaghetti and complex for no reason.
More or less:
1 - You don't mix things. You aggregate by feature instead of technical concerns (not all features are endpoints or require mapping, for example).
2 - Quite the opposite. Sometimes is far more complex to have to navigate through multiple classes to perform simple actions.
User type and puts a tape of both are in the same folder that's not ddD, obviously, The two do not belong the same bounder context. No bundled that the in the structure.
I recently started looking into functional programming, where we only have immutable data and functions. According to object-oriented programming (OOP), this is essentially an anemic model. Given that the anemic model is considered an anti-pattern, does this mean that functional programming is an anti-pattern for implementing Domain-Driven Design (DDD)? Or is it considered an anti-pattern only within the context of OOP? Sorry if this question might sound stupid, but with all this terminology and anti patterns it becomes confusing .
As mentioned, I don't think its an anti-pattern at all. I think what makes it an antipattern in on context of OOP is when you *think* you have a rich domain model encapsulating behavior and in reality is you don't.
It's not a stupid question. In FP, any function that would mutate the aggregate would return the new state of the aggregate. The original aggregate would remain untouched. I hope that makes sense to you?
Implementing DDD using FP... Hmmm, interesting and masochistic way to put the ball into square hole smaller than the ball 😂
Don't agree. That Like() method on the Post doesn't scale in terms of development. The Post class enforces consistency, but also introduces strong coupling. With increasing number of requirements, the post class will become a bottleneck. Imagine we want to react to posts, report a post, share a post, upvote/downvote a post etc. You'll keep adding those methods and counts to that Post class? Probably, you'll have a different stakeholder for each of those features, so now every time there is a change or a bug in one of those requirements, you'll need to touch the class which might affect other features as well. The transaction script approach will stay simple. New feature for a post is just a new transaction script, a change or a bug in that feature affects only that code.
Everything works fine when it is pretty clear and simple with few line of code. But when it gets super complex people got stuck and that’s approach not working in real life scenarios!
5 years of "experience" here.... I don't think i understand what they both are talking about. Although i watched a lot of architecture videos(Ardalis, CodeOpinion). I have practiced all this on my own, but still can't get really into it :(. I really admire Derek videos, as i see him as great professional. But the videos i watch, almost every time leaves more questions than answers. As the videos are short with already existing logic, and even pauses don't really help. I wish i could get into what Derek says quickly.
There is Tim Corey, who explains things really slow and in understandable manner. But he covers only beginner stuff without diving into architecture subject.
Microsoft has their shop on the web examples.
Some of them are deprecated but they have made 'books'/pdf that go over the architecture principles in them. One of them is made by Steve 'ardalis' smith.
They use Azure but just substitute that for any generic service.
Simple is always best. One problem though is that one person's definition of simple is not always the same as another person's definition of simple.
Thus why there are so many different architecture styles and ways to organize the code.
Eye of the beholder. Often simple and familiar play an odd role together in perception of simplicity.
But this is basically REPR design pattern by ardalis? (I'm not in C# so may miss the difference, but the Endpoint idea is pretty much there?) Afterwards you incrementally add layers as required
It's a transaction script built around HTTP at the end of the day, call it whatever you want.
It’s probably worth just spending some time mocking up a few approaches and just trying one that sucks less than the others.
.NET evolved to be very cool tech stack in recent years. Unfortunately, .NET devs are still stuck in 2000s.
we start 2000 , the change way much . most become not creative and sometimes become weird , you must follow of this or totally wrong . the worst interface just for unit test ? what happen ?😢
🎯 Key Takeaways for quick navigation:
00:00 *🏗️ Structuring HTTP API Projects*
- Different folder structures for organizing HTTP API projects.
- Common approaches include organizing by technical concerns, clean architecture, domain-driven design (DDD) with vertical slice architecture.
- Templates often lack indicators of actual DDD implementation.
01:24 *🗂️ Adopting a Simpler Approach*
- Emphasizing simplicity in project structure over strict adherence to domain-driven design (DDD) patterns.
- Advocating for vertical slice architecture for grouping features.
- Introducing an endpoints file for a clear overview of API surface.
02:21 *📁 Folder Structure Overview*
- Overview of the proposed folder structure: endpoints, common, feature, data.
- Explanation of the purpose of each folder in the structure.
- Focus on simplicity and ease of navigation.
03:32 *🔄 Endpoint Structure and Contracts*
- Explanation of endpoint structure: mapping, request and response contracts, logic.
- Importance of defining clear request and response contracts for each endpoint.
- Simplifying endpoint handling using static methods in minimal APIs.
07:15 *🧩 Handling Complexity Over Time*
- Discussion on managing complexity as projects evolve.
- Example of handling denormalized data and maintaining consistency.
- Evolution from simple transaction scripts to more complex patterns like repository pattern and event-driven architecture.
09:23 *🛠️ Balancing Simplicity and Complexity*
- Balancing simplicity with the need for more complex patterns as projects scale.
- Highlighting the importance of understanding coupling and applying solutions judiciously.
- Emphasizing the iterative nature of architectural decisions based on evolving project requirements.
Made with HARPA AI
Do not kill all those dreams, let them make DDD just creating some folders. Why someone will want to make things complicated adding things like ubiquitous language, a domain expert and all that stuff... let the data be transformed as is it to DTOs.
If you think DDD makes things harder you haven't been doing it nor applying design patterns to solve domain problems.
@@EldenFiend my comment was ironic, but I appreciate yours.
@@dlcardozo Ironic or srcastic? Either way, just sounded like it was for real. If not, I apologize.
it simple wait till 100 tables 😂 or 400 real project then headache
That guy doesn't understand DDD. I got that sense immediately as he mentioned it as he explains it and shows an example that is not DDD. 😅
Watch video once again, he said he's not using ddd.
Use a DB Trigger on the Likes table which increments on insert and decrements on delete. Done. Don't know why you want to put this into your application code
That's right there with sprocs, SQL Server programmability is alot easier to debug and find problems than your app code. Right?
Absolutely a solution (trigger). I was making up an example to illustrate consistency concerns, don't take it all to literally on solution to a made up problem.
All weird stuff begins with such a small pieces of logic spread through different system's layers. This a sooo cool journey to find where the problem is, starting with the presentation layer and going down the road to the db trigger.
it's good solutions when you don't have to react on the event inside your buisness layer.. but what if you have to?
Dude what you’re talking about ??? You are one of the problems here. Always overengineering everything !!!! I just want to f build a simple api dude Hahaha