-2

I'm a programming teacher. My students learn structured and then object oriented programming in JavaScript and C#. They learn SQL, MS SQL Server, Dapper and EntityFramework Core.

After this they make applications with data access code directly in the ASP.NET Core WebAPI controllers. I tell them not to do that, and teach them about layering, the old n-layer architecture, and the onion architecture reversing the dependencies. We work with testability and unit tests. And they learn to not expose objects of the domain model outside the application.

Let's assume that a full understanding of Domain Driven Design and CQRS are out of scope for my students, and/or assume that they will make some small and simple applications.

What architectural topics could I consider teaching them in this context? Another way of asking the same would be; in a simple application based on good object-oriented programming, ASP.NET Core WebAPI and SQL Server Db - and a Vue.js frontend, what would be a simple but still good architecture to consider?

  • If you're not going to go full-bore Onion, maybe Onion is not be the best architectural example for students new to architecture? They're already creating ASP.NET Web API with JSON endpoints, perhaps show them how to marry that to a browser frontend with Vue or something similar? Vue has the distinction of being a relatively shallow learning curve for small projects. – Robert Harvey Feb 25 at 20:25
  • Thanks. Yes, they learn Vue as well. In full born Onion, do you have to do DDD and CQRS? Or is it possible to do an Onion architecture without those? Actually, I think that's what I'm looking for, an Onion architecture without DDD and CQRS - and a reference implementation with actual code to look at. – Terje Kolderup Feb 25 at 21:37
  • According to Jeffery Palermo, you can call it "Onion" with or without the CQRS and DDD. CQRS is a Bertrand Meyer invention. DDD is an Eric Evans invention. Jeffery's recommendation for a "simple" Onion example is here. – Robert Harvey Feb 25 at 22:59
0

The most fundamental architectural question is:

What knows about what?

Look at any uml diagram and you’ll see lines going from box to box. The arrow heads tell you what knows about what and what doesn’t.

Isolating knowledge is the goal of every architectural principle you’ve mentioned. So yes more advanced techniques may be out of the scope of your classroom but simple abstraction is a darn good start. The value of good names that keep those who read your code from needing to repeatedly peek inside to remember what this does.

Keeping the CPU happy is one thing but good architectures keep the humans happy too. Good names and good abstractions keep me from wishing you’d just do it all in one file.

So how to teach that? Make them program to one spec. Then make them deal with a surprise change. Let them see the cost of not isolating knowledge. And make them read each other’s code.

You don’t have to prescribe an architecture here. Just give them a problem that shows the value of one.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.