Q:

DDD Handling Associations Between Two Domain Models Dependent Upon Each Other

Diving into the world of DDD is something of a whirlwind for me. While I've done a lot of research I'm struggling to change my thought process.
So, I have a package and a products entity. A package cannot function without products; vice-versa. The problem comes in when I'm needing to get the products belonging to a package (Note: the package is customisable, this means the products belonging to the package could be different the next time round). It seems that this belongs on neither entity, furthermore applying this to the package or product entity would make them tightly coupled. 
I must stress that I'm using the word association because I'm trying to figure this out on a domain level rather than infrastructure. 
A little thinking has led me to the following thoughts: 

Make Packages an Aggregate root & the products to be a sibling of the
Package entity. However I believe that both of the Package & Products
are entities due to them been uniquely identified.
Create a domain service that would take the package ID & map to the
infrastructure layer to find the associated products. However, this
seems rather long winded for a single look up.

It would be great if someone could turn me sane again! Thanks in advance!

A:

Ubiquitious Language
DDD is all about language - the key here is to listen to your domain experts talk about products and packages - how do they think about them? And about the processes involved in working with them?
When they create a package, do they really think to themselves "I must define products with this package", or do they think "I'll setup a package, and then link a few products to it" - if the latter, although it may on first blush feel like a package can't exist without products, notice the subtle implication in the timing - that the package can exist without products, because they expect to link products to it as a second step.
Given that, you might model the link as a completely independent aggregate with a single entity as the root, e.g. PackageProduct (or better yet, some term your domain experts use to define the assocation) and simply create new instances of this aggregate when a product is linked to a package.  This entity would have a PackageId and a ProductId on it.
However, if there are business rules, e.g. a Package can only have one product of a given type, or at most 5 products, then make the PackageProduct entity an entity within the Package aggregate, which has Package as the aggregate root.  The PackageProduct would have a reference to the Package and a property of the ProductId. See below for some terminology clarification.
Entities vs Aggregates
Based on your question, it seems there might be some confusion about terminology.  In DDD, we have:

Entities:

Have an identity that outlasts any given property
Has a mutable state
Generally, modelling business processes is all about working out how to mutate the state of entities

Aggregate

A group of entities over which invariants must be enforced

invariants are business rules that MUST hold at all times

A single entity is always nominated as the 'aggregate root'
Other entities can only refer to the aggregate by the root
When modelling a business process in order to mutate state, the aggregate is the boundary within which the states of all entities must be consistent with the invariants.
Outside the aggregate boundary, other entities may get updated asynchronously - aiming for eventual consistency

Domain Service

A service that contains business logic that doesn't belong in a single entity
It is generally not just a wrapper around a piece of infrastructure

See https://lostechies.com/jimmybogard/2008/05/21/entities-value-objects-aggregates-and-roots/ for more info.
Read vs Write Operations

The problem comes in when I'm needing to get the products belonging to a package

This sounds a lot like it might be in order to support a UI or a report?  In which case - don't stress about the entity model. The entity model is there to ensure the business rules hold while users are trying to modify the state of the system.  When doing a read operation, there is no need to modify the state, so you can bypass the model.  Define a query that projects your data store onto a DTO and tailor the the projection to suite the needs of the UI or report.

