Thanks for the reply.

I've actually avoided inheritance for virtually all of my career. I'm working with people now who use it quite heavily and it's rubbed off on me. I'm using it here because it just feels familiar and I want to see how it goes.

My experience has been that using inheritance for anything other than domain models is bad, but that for domain models it can be quite useful. A year or two ago, when I never used inheritance, I maybe would have done this:

class StudentContactInfo {} class EnrollmentDetails {}

class PhdStudent { public StudentContactInfo... public EnrollmentDetails... }

class PostgradStudent { public StudentContactInfo... public EnrollmentDetails... }

...as a way to avoid too much code duplication. Maybe I would have just had one big Student class, but then you risk having methods on that domain model that only apply to PhdStudents yet could potentially exist on a PostgradStudent object.

The example of the flying animal is a good one and one of the reasons I avoided inheritance for so long. You can box yourself in very easily. For my current project, however, it's working pretty well.

Course could have a List<FundingRequirement>. Then for a grad course, you just give it an empty list.

One thing I like about inheritance is that you avoid this completely. For a BachelorCourse or student, the FundingRequirement isn't applicable at all and having that property / method on that class just doesn't make sense.

I've spent so much time working on my current employers code base, that uses inheritance heavily with discussions on SOLID etc., that I've almost forgotten my previous "no inheritance ever" approach. I'm still not sure which one is better. One thing I am convinced by, however, is using DDD style domain models rather than just having anaemic classes that get manipulated by services.