How do I design entities in business layer of a multi-tenant application for an extendable database structure?

Question

For example, I want that a product may have multi-versions like from different tenants, one version product has 3 fields and other has 6 fields. Then how will I represent this entity in business layer to apply logic of my business on, not in database, of my application. How to know the semantics of the entities on the fly without a static class.

I know how to design the database. I asked about the design in business layer. Where I have business logic for different tenants with different requirements for an entity or many of them. How to handle that when I don't have a specific entity to add methods on? I don't have a product with static properties. How will I add many different discount formulas on an abstract database column that is stored in database only. How to convey different versions of the entity from database to business layer for processing and then to the web client for display and edits. How to represent it between web client and database where it will be processed, the business layer!

Answer 1

How to know the semantics of the entities on the fly without a static class.

It is responsibility of your code. If your product is tenant-dependent then the only thing you need is to check your tenant on the fly and choose the right logic.

I know how to design the database. I asked about the design in business layer. Where I have business logic for different tenants with different requirements for an entity orto many of them. How to handle that when I don't have a specific entity to add methods on

I would use tenant-dependent strategies to solve it.

Strategy (GoF patterns): This pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable at runtime. This pattern is used when you have some logic and you want it to vary independently of the client who uses it while still having an extensible model.

To solve the next issue,

How to convey different versions of the entity from database to business layer for processing and then to the web client for display and edits.

I think, you can use either inheritance or expose product's properties as single one generic collection of properties.

Anyway you are the one who knows your project and can choose the better solution. There is no silver bullet.