Clean architecture aka ports and adapters is simply an approach to building systems that follow DIP. That is, depend on abstractions not implementations, and make sure those abstractions don’t depend on details. #dotnet#cleanarchitecture
It doesn’t make exceptions for different kinds of implementations. It doesn’t exclude web services or email sending or file system access. Why would it be inconsistent about persistence or ORM usage?
If you find it useful to bypass using an abstraction (you control) in favor of relying directly on an implementation detail, go ahead and do so! Your app will still work! But the first law of architecture is everything is a trade off so just understand the pros and cons.
And don’t try to claim that such exceptions are “still using clean architecture” because they really aren’t. They’re exceptions because they’re bypassing the architecture that you may otherwise be using as it’s intended.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Everybody in the software development industry understands that learning is important if you wish to stay relevant over the long term.
So, it helps to have some kind of strategy or process for learning. You have one, even if it's just a random, default one. The fact that you're reading this means you likely incorporate twitter as part of your learning strategy.
But if you ask most developers about their learning strategy, whether thought-out or not, you're likely only going to hear them talk about their sources of learning.
If every software developer graduated college with a bachelor’s degree that included all of the things we wish it did, it would be at least an 8 year degree.
Most 4-year degrees already are chock full of required courses leaving little room for electives (and often only a handful of courses on one’s MAJOR).
When people talk about how our colleges are failing us by not producing graduates with X skill, it’s rare to also hear “specifically instead of Y skill”.
It’s like people don’t realize it’s a zero sum game.
A while ago before package managers and in dotnet land, nuget, many devs would put the dependencies their project needed to build in a “lib” folder.
Then package managers took off and became stable and trustworthy (for the most part), and distributed source control made it even more important to keep checked in code small.
Most developers embraced package managers and would check in just a manifest of their app’s dependent libraries/libs.
But some more conservative developers were less open to change.
I'm working on a new workshop that will guide students through an array of different data access approaches for OO languages (.NET/C# specifically). I like to start such topics off with principles that apply to the space. Here's what I have so far - am I missing anything obvious?
These are "data access principles" which when I searched I didn't find any handy lists. I'll probably write up a blog post on the topic soon.
Acquire late; release early.
This applies to any shared, external resource, such as a database connection. It's a low level principle that most modern developers don't even think about, but I think it's still worth mentioning.
So you find that now you're suddenly going to #WorkFromHome? Here are some tips I've picked up over the years, on how to be productive and also participate in teams without being in the same room or face-to-face. (Thread)
It helps if your team is remote-first. If everyone just got sent home because of COVID-19 concerns, then the upside is that you're not the lone remote worker on a team who are otherwise all together. So you're not going to miss out on hallway conversations, etc.
Going "remote first" as a team means that all important (and even casual) communication happens on channels that are accessible to remote staff. That typically means email and Slack/Discord/chat as well as Teams/Zoom/GoToMeeting.
Most never move off of this model, but it has disadvantages that go along with the ease of sharing data. Applications lack encapsulation and cannot adapt their data designs to suit their unique requirements.
Usually the next approach is to treat applications just like components, with exposed public APIs. However, this can result in increased down time since direct API communication between applications means if any is down, the whole thing is down.