Random reminder that I have a YouTube channel where I post videos about software architecture and design. Usually in the 10 min range trying be concise as possible. If you enjoy please share. Have suggestions? Please let me know.
This weekend I'm going to work on my next video about how Microservices (or any size service) have absolutely nothing to do with Container/Docker/K8s. I can't deal with reading these articles anymore. Next to nobody mentions it's about logical separation and not physical.
I'm creating a series of videos that will take an existing sample app and move a portion of it to be event sourced. Along the way, I'll be removing a bunch of layers and "services" which I think will give a better gist of Vertical Slices and how that plays with CQRS.
Blogged: When building Software as a Service (SaaS) you’ll often need to use a Multi-tenant Architecture. There are many different ways that you can segregate and share compute and data storage in a multi-tenant architecture.
I really don't understand having the defined role of "Software Architect". The architecture will evolve by the team. Someone on the team can be leading that charge. Everyone on the team can have varying degrees of input but ultimately it should involve everyone.
I love code. I love writing code. I love creating software. The challenging part in the software I write isn't writing the actual code. It's understanding the domain, really understanding. Then translating that to code, evolving the design and architecture over time.
I'm really curious about the software industry's love for making language/framework/tools the top priority of knowledge and experience. Why isn't the type/domain of software you develop the most important thing? Ex, hiring C# developer vs. hiring a developer for insurance.
Recently crossed the 50k subscribers mark. It's been a long road over the past few years. I try not to concern myself with the subscriber count, but it's hard not to notice. These videos aren't for everyone, but I appreciate everyone watching, liking, and commenting.
Friendly reminder that I have a YouTube channel that has over 100 videos about Software Architecture and Design. New content every week. If you enjoy my channel, please share!
Blogged: Everyone creating HTTP APIs seems to implement error responses differently. Wouldn't it be great if HTTP API Errors had a standard? Well there is! It's called Problem Details.
I finally read the Amazon AWS Lambda thing that was all the rage last week. Most of the takes I read were head-scratchers or just clickbait, I guess... It didn't help that the post stated it was moving from Microservices to a Monolith. From the post, they kept the logical
Some *interesting* replies. If you write CRUD-type systems primarily without "business logic" go talk to the people using it. The business logic is in their head. Watch their workflow and ask what they're actually doing and why. Guess what you'll discover, business logic.
CRUD based apps leave workflows and processes up to the end user (in their head). Task based apps drive the user through workflow. Trying to shove business logic into CRUD driven "entity services" is recipe for a brittle system.
Why is clean architecture so popular? I believe people want and use it as a prescription. Unfortunately, not all contexts have the exact needs for various levels of abstraction and stability. Context is King.
My continued .NET Core migration saga. We're running on 3.1 now in production. Anyone interested in a video of *my* entire saga (all aspects) of moving a large web app from .NET Framework to .NET Core 3? If so, any particular things you want answered?
What’s the biggest scam in tech that is deemed acceptable? Best practices. Everything has trade-offs and your context matters. Let me give various examples to get out of this dogma about best practices.
Well, I was not expecting to migrate a small WinForms app to .NET Core 3.1 today. I did not read the docs at all. I simply did a dotnet new winforms in a new folder, copied over all my existing files to the new folder, added appropriate package references. Bingo Bango, it runs.
Can I mute all the one-sided conversations about Code Reviews, PR, and other nonsense? Can teams just figure out what works best for them that delivers the best working software and just do that. Can we start being pragmatic? Probably not but I still hold out hope.
Blogged: Is CQRS Complicated?
CQRS is often referenced alongside other patterns that can make it seem difficult and complicated. Is CQRS complicated? No. CQRS is simple. Really simple.
Developer: I'm writing this hacky code that's a turd pile because I'm getting pressure to get this done. Oh well.
Same developer on a different existing project: Look at this crappy code. Who is the brutal developer that wrote this hot mess? What were they thinking?
Genuinely curious how people who do content "full time" don't lose touch with the reality of the industry? Meaning that if you're not in the trenches of production systems. I'm coming at this from my own angle: everything I post is based on experience in production systems.
Blogged: If you’re developing an HTTP API how does that fit alongside a Task-Based UI and CQRS? How can you create a REST API with CQRS? For starters, resources don’t need to map to Entities. Second, HTTP Methods don’t need to map to CRUD.
Video: Want to see an example of how CQRS & Event Sourcing work together? Here's a code walk-through that illustrates CQRS, Event Sourcing, and Projections.
Underrated skill (?): Critical Thinking. You'd think we as developers have this, but we seemingly lose all ability when something is "best practice", or it's "what we do" without thinking about our own context and if it serves us value.
Why is Clean Architecture so popular? I guess people are tired of working or creating turd piles that are poorly structured with mixed concerns. Ultimately it addresses coupling. But what about cohesion?
99% of problems can be solved by a website with some JavaScript calling a Python REST API that queries an SQL database.
Stop chasing the decisions of people with problems several orders of magnitude more complex than yours unless you understand why they did it.
Friendly reminder that I have a YouTube channel about Software Architecture and Design. Please share and spread the word if you find the videos helpful.
Event Sourcing is seemingly constantly being confused with Event Driven Architecture. In this blog/video I'm clarifying the difference. You will introduce a whole set a problems if you conflate the two.
Friendly reminder of my YouTube channel where I focus on Software Architecture and Design. Pretty good library now of videos with a new video every week! Please share if you find them helpful.
Just noticed that my YouTube channel passed 40k subscribers 🎉. For those that watch and subscribed, thank you! I'll continue to post my nonsense opinions 😂
I don't create abstraction "in case the underlying implementation needs to change". I create them to simplify the API surface. If I don't need to do that, don't create more indirection. Abstraction or no abstraction, limit coupling and "in case it changes" becomes less relevant.
Almost every video I watched about domain modeling started with creating data models and calling them entities. Very few of them talk about the actual domain concepts about how that data comes to be. As a whole, little has changed regarding modeling a domain in the past 20+
I'm not sure why exactly, but I have almost zero interest in Blazor. And this coming from someone that thinks frontend JS ecosystem is a tire fire. You'd think I'd be excited about this yet... meh.
Microservices vs monolith seems to be a thing I keep seeing more of. Once the larger dev community can figure out that logical boundaries aren't physical boundaries we'll be over this nonsense.
Synchronous request/response is tight coupling. It doesn't matter if it's in-process or RPC. Tossing HTTP calls between services doesn't make anything less coupled.
The most impressive engineers in my experience are ones that can transparently jump between the layers of the stack. Up to the UI and down to the assembly (ok maybe not that low...)
I'm on a mission to create a video illustrating how useless an object model (aggregate) is with a bunch of SetPropertyThingy(value) methods. Serves absolutely no purpose. The template of WebAPI > AppLayer > Repository > Data Model with useless setters needs to die in a tire fire
McDonald's uses an event-driven architecture! I love it when companies have technical blog posts. I gave some of my thoughts and did a breakdown of what they posted.
Fairly sure when you say "unit" tests, what most developers (in OO) really think are "class" tests. If more than one class involved they then equate that to integration.
You often think of messages as fire and forget. Send a command to a queue, and the consumer handles it asynchronously. You don't know when the message was processed or the result. However, there is a solution!
I've noticed that "Software Developer" YouTube is much like "Fitness" YouTube. There's a ton of bad information and the overwhelming majority of it is targeted at beginners.
Separation of concerns, principles, yadda yadda, yet I see over and over a data model also being used as a domain model. What's more amusing is "persistence ignorance" as a driver and it's absolutely affecting your design. Even if you didn't want to use event sourcing, I think if
After 20+ years, I'd suspect my code is closer to the earlier years than around the ~10 year mark. Earlier years were simpler but naive. Middle years were "flow a crap ton of patterns because reasons". I hope that blog/videos can help others with that middle part to be pragmatic.
“Clean Architecture” and indirection. No thanks.
I reviewed a video that was trying to apply the query side of CQRS by adding a whole lot of useless indirection. Please don't do this.
You don't need an interface for everything! You can design and use different abstractions where appropriate. Not everything needs an interface and mocking to be deterministic.
Based on YouTube comments, I get the feeling there are many people with "Sr. Developer" titles that should be "Sr. Hot Mess Maker." Reading some of these comments makes me feel bad for Jr. devs trying to sort through it and likely being shot down for suggesting it's too complex.
I'll never convince some folks that useless abstractions and indirection add no value (net negative). Just because you're not abstracting dependencies does not mean you're going to be stuck with them and have technical debt. Define boundaries (cohesion). Control coupling. Period.
One of the building blocks of messaging is, you guessed it, messages! But there are different kinds of messages: Commands and Events. So what's the difference? They have distinct purposes, usage, naming, ownership, and more!
Consistency is critical when working with an event-driven architecture. You must ensure that when you make state changes to your database, the relevant events you want to publish are published. You can’t fail to publish events.
Just passed 14k subscribers on my YouTube channel. Goal at the beginning of the year was 15k. Although total subs means nothing, I do think I've got a pretty engaged community happening. I appreciate all the comments, views, and likes.
Can someone explain why many developers won't pay for crap? "That library is great but it's got extension features that are paid and I'm not buying it". Are they afraid to ask their manager/procurement? I get people working in all kinds of orgs that make it difficult, but it's
After reading some puzzling comments on Reddit, I'm creating a video on DDD. Stop caring so much about the structural/pattern nonsense and start caring about the domain, modeling, language, and boundaries.
@ardalis
@TheCodeJunkie
I was once given the advice to ask someone the downsides/pain/problems/tradeoffs of something they say they know deeply. It's a pretty good indicator of how deep their knowledge really runs. Doing so I've concluded a lot of folks' opinions are just the opinions of others.
You'd be surprised how far you can scale a monolith. There are a lot of options you have before you start to decompose into separate physical boundaries.
Coupling and Cohesion go hand in hand. Yet, cohesion is often left out of the conversation, and we focus on coupling. Then we organize our code based on coupling of technical concerns. Add cohesion to the forefront and start organizing code around it.
Domain-Driven Design sample/reference applications do more harm than good. In a vacuum, they’re a net negative. It isn’t easy to convey the complexity and trade-offs made using trivial code examples. They're the wrong starting point.
I'm convinced sample/reference applications do more harm than good for beginners. As in, they are overall a net negative. It isn't easy to illustrate why something is done when you're fabricating the context and scope of the problem.
I'd be happier with exhaustive pattern matching and an option type rather than nullable reference types in C#. Be done with all this nullable nonsense and move forward.