Distributed "architecture review" is such a fun format

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

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.

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 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.

Thanks a lot for a great video with the essential wisdom 👍

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.

🎯 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

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.

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.

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? 😢

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.

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.

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?

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

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 .

How do you prevent your team from adding db calls directly from endpoints in a single project structure?

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

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.

It’s probably worth just spending some time mocking up a few approaches and just trying one that sucks less than the others.

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.

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.

.NET evolved to be very cool tech stack in recent years. Unfortunately, .NET devs are still stuck in 2000s.

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.

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.

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. 😅

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

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