For this I would do exactly the same as you would in in your flat, non hierachal or structured SQL relational database, using 3 tables.
You could say that deals would be embedded into company and maybe they could be but if deals were changing often you could see fragmentation within the top level document due to non in-place updates.
An in-place update is specified by one which does not require the document to move to another part of the disk in order to be able to be stored. This is of course a lot faster and less over head than one which requires to be moved to a new contigeous part of the disk. Not only that but the left over space, if your unlucky, could be left there without ever being filled.
The only way to fix such a situation is to run a db.repair()
regularly which some users do for some reason.
Instead with that in mind and the usage and query patterns of deals I would think they should go into their own table.