We used to define business objects mostly as classes. But what if they become interfaces while instances will be created automatically from some factory (like IoC container)?
Philosophically let's imagine we are talking about some laptop. What is usually important for us? Probably it's technical specs. Especially when we're going to buy it. Tomorrow we have a flight and more important aspect of the laptop will be it's size and weight while we're packing it into our luggage. If you looking for something to hammer a nail the laptop will appear from the different point of view. So any object may have different aspects. And these aspect are interfaces.
Let's take a look briefly into advantages.
Firstly, you can't inject logic into schema that is not a good approach because highly couples responsibilities. For example, let's consider validation. When you're buying the laptop, you have specs-based validation. When going to flight, size/weight-based validation. So validation is process external to the object itself, made by subject and environment.
Secondly, even if you need some logic, it can be automatically or manually added to the implementation of this interface. And here you'll have a kind of AOP (Aspect Oriented Programming) where any aspects can be flexibly added to the objects.
Thirdly, designed based on interfaces is always more flexible. You'll start to extract different aspects of your classes, because won't be limited by "inheritance hell" and can easily build mixes from different interfaces to craft new view-models, DTO models (requests, responses), etc.
Simple example. Many objects have Name property. Event if they are very different and you can't provide the property by inheritance. This is a specific aspect of "named" things. Or some "hierarchy" aspect that defines Parent property.
A good solution is to define it in IHasName interface. For this interface you can define validation rule, that will be automatically injected into property setter when your IoC will create an instance with this interface.
