The style of structuring code described in the article is one that I use too. It took 2-3 years of writing C# to settle on it, and it works extremely well for m

The style of structuring code described in the article is one that I use too. It took 2-3 years of writing C# to settle on it, and it works extremely well for me. It's nice to see someone else enjoying the same style. For me, I mostly use plain data classes with no behavior at all, and stateless "service" classes. The services are just a collection of a few pure functions, often with several other service dependencies. I group these based on single responsibility. Occasionally I'll have a more traditional stateful class, but they're in the minority. I glue these bits together around the edges where the systems have to talk to the database or deal with other external services. I use interfaces mostly to facilitate testing, so I can mock them. Pure, composed services are easy to test. Another thing that helps me keep things simple is making sure each "silo" of functionality has separate data models for exporting data and internal representation of data. For example, I use a separate class for deserializing a config file as I use for actually using the config. I am often mapping some class from one area to another, because the two areas have different use cases and needs. I've never used WPF, so the parts particular to that didn't resonate as well with me. But it was a great read.