Should a domain object wrap/contain a DTO interface

Does it make sense for each module to have their own version of an inventory item that is designed to suit the needs of that module? In that case, the Financial module would have to perform its own lookup of the inventory items when handling the GoodsReceivedEvent. Where do I draw the line between modularity and the need to share information?

You will always have to accept trade-offs. That's all there's to say to your questions really. It has been a good practice to keep the entities in a separate assembly, so many applications keep them in a shared library. But that means that there're no (physical) business-logical boundries. Performing your own lookups means a lot of redundant code which I'd only implement if you have special requirements in both the modules. Of course, looking at it from an architectural point of view, your Financial Module and your Inventory Module have to share a dependency anyway. The Financial Module is most likely dependent on the Inventory Module. If requirements permit you to let one module depend on another module, then I'd say it's ok to encapsulate the entities within the modules they belong to the most. You'll need to find a good balance between physical distinction (shared dependencies) and maintenance. Too many shared dependencies could cause a maintenance nightmare of versions. Also, with an ORM there'll be troubles if you want to map new relations to existing entities or extend them from modules which depend on the module containing the entity.

If you don't use ORM then keep in mind all your modules probably share the same database anyway, as that's often the case. You could use that as a common ground.

You could also keep the data plain (in terms of CSV/resultsets e.g.) and use a central messaging service to notify modules that registered to it about new data with along with some meta information. That means no real dependencies, but sacrifices type safty and contracts and there can be troubles with malformed data. I guess that's how many big ERP systems do it.

So in short, you'll have to decide which kind of interface you want. More modularity leads to less contracts and vice versa.

Id'probably use a shared library for my data objects and a central messaging service with a publish subscibe pattern, that seems the best solution to me.

a) DDD doesn't specify that domain objects shouldn't create domain objects. A domain object can very well create another domain object. An aggregate is responsible for enforcing a consistency boundary around a cluster of entities and value objects. As such, it could very well have behaviors which create entities. For example, the stereotypical sales order aggregate can create instances of order line entities (or value objects, depending on implementation). The important thing is to ensure that domain and entities are created or deleted in well defined places. Take a look at this article which evaluates aggregate creation in a domain model.

b) The mapping between a real world entity and the corresponding abstraction in code is never isomorphic. Abstractions in code are bound by technical constraints that cannot be overlooked. Code isn't meant to be an isomorphism of reality, it is only meant exhibit functional characteristics which fulfill sets of requirements. The similarity between reality and code is an aspect that we strive for to streamline the development process. In other words, if a real world entity creates something, it doesn't immediately translate to the corresponding abstraction in code, though it may - there is no hard rule.