Replies: 3 comments 8 replies
-
We want to modernize the code and make it a show case for how to build cloud native applications for .NET 8 and beyond. That means showing off features and best practices (that many may not know exist). It's already started in the dev branch. Some of the items are captured here. There's a lot of clean up passes happening first (code style, removing unused code, removing over abstraction etc). Some high-level thoughts:
Other ideas include:
|
Beta Was this translation helpful? Give feedback.
-
|
Dev blog would be quite osme overhead, maybe we can live stream on the stand up and discuss some of the upcoming changes cc @jongalloway |
Beta Was this translation helpful? Give feedback.
-
|
anything that is saved so in the future people could go step by step and understand the pieces slowly would be really helpful. I like this example but at the moment there is so much going on that I wish I could have been there from the beginning |
Beta Was this translation helpful? Give feedback.
-
|
There's an entire book! I agree with you that there's a lot going on. Hopefully we can make simplify and still make it understandable 😄. Improving the documentation along the way. |
Beta Was this translation helpful? Give feedback.
-
|
there is already a book that references this project and bit of it.. some microsoft book.... But the way I like to learn is understand the thought process as its being built.. so if you can do a few minutes on the pieces you added during one of your videos that is good. Or perhaps break the code into chapters.. for example... make sure you understand what is going on at every couple intervals and then goto next tag.. rather than trying to take in the entire project.. In the end I want to have the ability to create my own project and use it as a reference... and know how to deploy to the cloud... |
Beta Was this translation helpful? Give feedback.
-
|
Hi @davidfowl, |
Beta Was this translation helpful? Give feedback.
-
|
Please don't take offense in my comments, but I think such a project would be great for software developers and teams to learn from. They could derive a development strategy of their own. I have seen way too many teams struggle... way too often. It's probably too much to ask for, because it's not as much fun as writing code and solving complex technical issues. And while I understand, that the Scope of this repository is probably to only showcase a Cloud-Native Microservice architecture, it could be so much more and help teams to find a way of working together. It could help teams to learn documenting their systems in a good and consistent way and learn about strategies to maintain their software and databases in the real world. DocumentationI see you are going straight to code in PR #2107 and technical details in the Epic. I know, that you are really good at software development! But Software development is so, so much more. And before a single line of code is written, it should be very clear where and how you are going to document a system. How are @ReubenBond and you going to document all decisions you are making along the way? Say in 5 years David and Reuben have left the team, I am reading through the system and wonder about a decision. Will I now have to jumanji through 5 years of GitHub issues and epics filled with irrelevant comments and vague ideas, or is there going to be a clean approach to documentation? Documentation should be fun and it should be living documentation, so it doesn't get outdated, irrelevant and invalid. And most importantly it shouldn't be punishment for developers to write documentation. I've found Arc42 to be an amazing tool for documenting systems, no matter the complexity the systems had. And it gives you a very good guideline for writing software system documentation. Maybe you have other approaches to documentation? I would be amazed to learn them. Writing documentation can actually be fun! Working in a TeamIf you are working in a team you have to communicate, communicate, communicate. And a lot of software developers aren't good at communicating. There's a huge psychological aspect to our profession. Often enough rockstars work nightshifts and create enormous Pull Requests, that are impossible for colleagues to digest... and that creates frustration. I have done this myself often enough, but these days I would simply decline a PR the size of PR #2107. Or what we all experienced once, is that Pull Requests are taken personal and drama occurs. I hate SCRUM with a passion, but there are few good things in it. Code of ConductAre you going to add some code of conduct and try to establish an inclusive culture? Like how do you want to work together as a team? What's important to you as a team or as a community? What are your values? How do you want to treat each other? Of course a code of conduct is only some nice words, if they are not being lived by and not being enforced. But once they are being enforced and checked, you will work better as a team. Again, we have not written a single line of code yet. Definition of DoneWhat's your "Definition of Done" to merge to the development branch? Did the Stakeholder you are developing this for understand the requirements? Did all developers understand why we are doing this? Have tests been written? Has the documentation been checked and updated? Did someone run Acceptance tests on the staging system? Yes, even simple stuff counts for me like "What do we want to have our commit messages to look like?", so we know every commit references an Issue we find some reasoning in. A Definition of Done really helps to make development easier. Development WorkflowBefore you do your first commit, you should agree on a development flow in your team and it should be defined somewhere. The documentation would be the right place. GitGit WorkflowI see you are having a "dev" branch and a "main" branch in here. Pull Requests are made to the "dev" branch and at "some point" they are going to be merged into main. But when is that "some point" exactely? When the epic is done? When two or three epics are done? When a bug is fixed? When a version has enough features? What about Bugfixes, that tend to happen in reality? Basically what's your Git workflow? It's obviously not Trunk-based development, but it also doesn't look like gitflow. What is it? You have to ask yourself questions like, do you have to support multiple version of your software in production? Or do you plan to only support a single version of the software and update all customers at once? Do you have multiple customers at all? While I found gitflow to be somewhat of an overkill, it gives you a good workflow for supporting multiple versions of a software in production. If you don't have a documented workflow, you are going to live the chaos. Merge StrategiesPR #2107 has a million commits like "Fixed something", "Deleted unused code". It will be quite hard to read this git log, because there so many small and irrelevant commit messages. What's your merging strategy? Are you going to squash all commits, so the logs look better? Or are you going to do a plain merge as is. Do all team members know this? I would at least try to find some agreement for commit messages, so that you reference an issue with context. EnvironmentsDo you plan to have a Development and Staging Environment? If so, where are we going to find the information? Are you going to use production database backups for the staging environment? Or do they contain sensitive data? Hey, you could also decide as a team, that you do not care about dev and staging environments, and test your stuff in production, like real man do! But again you should document that decision somewhere. ChangelogA Changelog is not only interesting for developers, but also for your second level support, potential customers and the DevOps crew. What has changed in this release? What could be the root cause for an issue, before I am going to the developers? Do we need to run database migrations or change configurations in this release? Where are you going to keep your Changelog and Release Notes? In a separate Hey, you could also decide to not care about a Changelog, Release notes and your customer or support crew. But again this decision should be documented somewhere for every team member and colleague to know. Database DesignSoftware developers focus so, so much on code and I have seen projects die in beauty so many times. "Oh, we are using Domain Driven Design and Clean Architecture! Vertical Slices! Value Objects!"... but just look into the issue tracker here, and see how long it took to get something as essential as Transactions to be right. What so many software developers forget is: Your application will die, but the data probably lives forever. Database ConventionsEven though your domain is admittely simple and there are few database entities, it would be great to see some planned approach to database design. If you are going to work with PostgreSQL, then make sure to at least apply naming conventions for database objects. EntityFramework Core makes it easy to get started, but using a Code-First approach without using any established conventions for the database system in use, makes it not only hard for your DBAs to understand your database, but it makes it hard for developers to "name things". Define the naming conventions you are applying somewhere, a documentation would be a good place. And make sure everyone in a team knows how to name things, else chaos is going to happen. This is what I use for SQL Server Database conventions, it's probably a good starting point, something similar can be derived for PostgreSQL for sure:
Database Migrations"Wow, this Code-First stuff is so cool! You can run migrations from Command Line!". And then one day you are living in the real world, where entire companies depend on this SQL Server instance and you are basically sweating blood and tears with every deployment. I cannot and do not want to speak for requirements of other developers. But no one in their right mind runs automatic migrations on production databases at startup. No DBA is going to take any responsibility for this, I wouldn't do so either. So how are you going to migrate your database? I have often seen SQL scripts being generated from the Code-First Migrations. Do you also plan to go this route? Do you want to version SQL migration scripts? Or do you trust your Code-Migrations enough, and trust that, EF Core 3.0 is going to generate the exact same SQL as EF Core 6.0? I wouldn't bet on it, your DBA wouldn't bet on it. And I would love to know what has really been applied. SQL Server Database Projects or DACPAC are magnificient tools for working with SQL Server databases. You can easily generate migration scripts, you can easily generate a diff between databases, you can safely deploy using it. Why is none of this showcased? It would be amazing to see it somewhere in either Microsoft's projects. The best database project I have seen so far in Microsofts Open Source repositories is the Wide World Importers database: It probably gives some inspiration. Final WordsWhat I basically want to say is: This eShopOnContainers repository is something, that people use for their applications. They are going to take all this in here as best practices, that Microsoft experts have developed. The handle @davidfowl on it, even gives it more credibility. Think through how people can maintain such a system in production, how they are going to migrate their databases, how they are going to migrate their messages in their RabbitMQ topics, and whatever Orleans is using for persisting state. Make sure to know how you are going to version your gRPC endpoints and protobuf files. Not being able to answer most of these questions puts frustrations and pain on developers, and it puts pain on anyone involved in working on the system. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for this epic comment. I'll try to answer as best as I can.
Since this is a show case project and not a real one, we might be able to find some middle ground here by documenting why we chose some of the decisions and writing them down in the repo. Maybe something like this. It's worth thinking about a little, because @ReubenBond and I ran into the same problem before we started refactoring the current code base.
I would too, the PR is really unreviewable, we are mostly trying to get the code into a "good state" before we make any real changes. Most of those changes are clean up, and modernization (fixing namespaces, sharing common code etc). Once get to a good state hopefully the PRs will be more manageable.
I'm not sure how this would differ from any other code of conduct on any of the Microsoft repositories.
Yes, we should be squashing, this branch got too big so we wanted to merge it before it got any bigger. I agree some of those commits should be cleaned up before the big merge.
I like this idea. Actually keeping this site deployed like a real application that is maintained should be one of the goals.
We might not need one if we're doing commits and releases properly. We might be able to generate release notes instead. We'll take it into consideration!
Thanks for this epic comment, we have some more work to do! The hardest part about it being a sample is that it will never 100% meet these expectations, but we can do ALOT more than we do today WRT documenting decisions. While it cannot mirror all the aspects of a real project, we can maybe find a decent middle ground. |
Beta Was this translation helpful? Give feedback.
-
|
@davidfowl Thanks for your kind reply. I didn't want to write an epic comment, but... my fingers just kept on typing. The thing is, that this is one of the few chances to get a message across. This repository is the closest thing to an "official" Reference Architecture in .NET, that Microsoft has to offer. And software developers are going to take all this in here as best practice. So it has very, very realistic consequences for me as a .NET developer, because software systems I am going to work on will be modeled after this one. All I wanted to say is, that a good documentation is important to not be the single source of truth, have everyone standing at your desk and finally rage quit from burnout. Just yesterday I read a good article by Vadim Kravcenko: As for simplifying these Onion Architecture applications, I found "Cleaning Clean Architecture" an enjoyable read: I am sure, that you'll find a way and thanks again for not taking offense. |
Beta Was this translation helpful? Give feedback.
-
|
@davidfowl Meanwhile I have written an article on Relationship-based Access Control at: https://www.bytefish.de/blog/aspnetcore_rebac.html. The code is at https://github.com/bytefish/RebacExperiments. It shows a "different way" of building .NET applications (and use the new If you combine a database-first approach with the "EntityFramwork Core Power Tools" VS Extension by @ErikEJ, then you have a nice way of generating the DbContext automagically... without having to learn any kind of command line switches. It would be great to get some feedback on it. I am closing this discussion and again thanks for your kind messages. |
Beta Was this translation helpful? Give feedback.
-
Hi @davidfowl,
I have seen on Twitter, that you are planning to rewrite the eShopOnContainers sample. I love this idea! And I would love to initiate some kind of discussion, so we as software developers can participate, learn and grow.
To be totally honest. When I have looked at the original eShopOnContainers application, back in the days, I have brushed it off as being over complicated. I don’t want to come off as negative, but a “Domain Driven Design” approach with “CQRS” probably overwhelms most teams I have been in.
I would love to get some hints and your ideas.
Why do you think a rewrite is necessary and justified? What’s your broad plan for the future architecture to look like, even if it hasn’t been fully formed yet? What are your plans to migrate the existing code to it?
It’s just, I would love to get some insights to the thought process of you and the people involved in the rewrite. Because I have been in very similar situations before and would love to see how other people approach it.
Thanks for your time!
Beta Was this translation helpful? Give feedback.
All reactions