better approach to design company hierarchies in table
If your hierarchy is rigid (i.e. the levels are consistent and mandatory) then there is nothing wrong with representing each level as it's own table.  This is your first option, except that instead of having foreign keys on the person table to each of the organization levels, you should have a single foreign key on the person table to the leaf level of your organization, and then each level in turn refers to it's parent/container.  i.e.:

Person => Service => Team => Group => Domain => Company

With this modification, your tables will be in third normal form (3NF) which is always a good starting point from a design perspective.

If, on the other hand, your hierarchy might be at all fluid, then keeping a hierarchy in a single table with a self-referencing (involuted) foreign key is a better option from a code stability perspective.  This is your second option.

One issue with this second option is that relational databases are not brilliant at handling unleveled trees in this form.  There are, however, a couple of pretty useful techniques for managing this type of data in this format a little more easily.  You can Google around for adjacency lists and visitation numbers to learn more.