Better design pattern for implementing ever changing components

Background: The product has the following classes (entities):

1. Module
2. Department
3. Layout
4. Field

The relationships goes like this:

• Module can be department specific or not.
• Module has layout.
• Layout has Fields.
• Fields can be of many types. (Number, Line, DropDown, etc.)
• Fields are module specific. That means field and layouts of module has many to many relationship.
• Fields normally have module specific properties which clients use via one api.
• There is another api that renders layouts and their corresponding fields. These have few extra details (like whether the field is mandatory in the module or not, etc.)

Problem: I need to refactor this entire sub system into proper design and make proper classes such that it solves our current use case and also for future use cases.

Currently, we have two classes for fields. One to show only module specific details and type specific details. Another that shows these along with layout specific details.

I don't want to duplicate this much of code. So, I have came up with 2 solutions:

• Make an abstract class for fields which contains all the properties common to all field types. Then for each field type, create a new field. In this way, new types can be added easily. Also keep a bunch of interfaces as strategies - LayoutProperties, License, etc. This approach looks good but feels like slowly the abstract class will turn into god class.
• Similar to above. Create abstract classes and put common details. And create different class for sub classes. But Create a separate interface like LayoutDetails. Each field type is then again extended to create a new field which also has layout related properties.

Both approach seem to be workable but doesn't seem clean to me. Can anyone advise on whether I am on the right track or I am missing any design pattern that will be better suited for this problem. I can share some basic code if it will help.