Architecture complexity in the dotnet community & Our duty to beginners

I have noticed that dotnet community seems default to a lot of complexity for their software.I see a lot questions often by beginners about clean architecture, domain and persistence layers, repositories + UoW patterns, dtos, mapping code between domain, persistence & dto layers, mapping code & keeping change tracking by introducing diff libaries etc More so than any other community.Why is this? When you search online as a beginner these are often the first articles that appear. Often by consultants or thought leaders trying to build a brand. Keep that in mind. I’ve turned up at companies where their simple CRUD app has UoW+Repositories, Clean architecture and various mapping layers. Clearly people have read tutorials & tried to blindly apply them.Simple pieces of software end up with 6 projects, 70 files, most of the code is about mapping between different layers rather than application logic. Are people being paid by the line? This is often for simple domains with low to medium levels business logic complexity. In these cases technical complexity has exceeded the business logic complexity and harmed maintainability.I would like to highlight the most important architecture concern is the ability to add in complexity incrementally as you need it. The best piece of code, is code that you didn’t write or have to maintain.For example do you need a dto, when the original object and dto are the same shape? Not at first. When do you add it? When they deviate or your app is starting to grow and you foresee difficulty in the future unless you add it now. Normally when a significant amount of files start referencing it. Do you need a rich domain model at first? No. When do you add it? When transaction scripts start duplicating logic & your app is starting to grow. Most of these patterns fix certain problems, apply them when the problem appears.For small & medium size apps you rarely get to this point. So you never needed the dto and mapping layer. Mapping layers increase the risk of insidious bugs being produced. People resort to Automapper to fight boiler plate, which wasn’t required in the first place. Then automapper converts compile time issues into runtime issues, which you require a decent set of tests to cover. Those tests are unneeded technical complexity, you will now have to maintain. Ending up with a mapping layer, extra objects and a whole bunch of tests which you didn’t need with extra risk around mapping issues introduced.Personally I avoid auto mapper, because at the point your writing a decent set of tests against mapping code, I’d rather just write the mapping code manually and get compile time guarantees and a smaller set of tests.I would like to stress the importance of cutting back on accidental technical complexity, until you need it. Experienced people try to cut back on complexity until it is required. We have to highlight this to beginners and bring it in as the default view in the community. Always question the need for complexity, and only add it in when it is justified. Software design is full of trade offs and their isn’t a “correct” way, and being a good designer is balancing these trade offs and adjusting as you go. via /r/dotnet https://ift.tt/2NDjWvC