[Question] Module Encapsulation / Dependency

[boxxroom]

Thanks very much for your talk on Laracon, it was insightful and couldn't have come at a more fitting time.

I am a big fan of the Actions paradigm and already using this on a Domain level, more inline with Brents, Laravel Beyond Crud (https://laravel-beyond-crud.com/) from Spatie but will now be adding a contract to Actions as shown from Luke Downing's Laracon talk. To incorporate incapsulated domain level Actions within Modules (for me) would be the icing on the cake.

My question:

Isn't the Orders module dependant on the Inventory module or at the very least a skinny version of the Inventory module in order to work correctly. (Reasoning below)

Exploring this repo's codebase, I really like the structure and how everything belongs to that module, but I couldn't help but notice (please correct me if I am wrong) there was a dependency required from another module in order for a given module to work correctly. The module I refer to is the Orders module, specifically the Order Model requiring a ProductDto contract (interface) from the Inventory module.

modular-monolith-laravel/src/Order/Domain/Models/Order.php

Line 11 in 291dc78

use Laracon\Inventory\Contracts\DataTransferObjects\ProductDto;

modular-monolith-laravel/src/Order/Domain/Models/Order.php

Line 44 in 291dc78

public function addOrderLine(ProductDto $product, int $quantity): void

"Thinking out allowed"

I'm not entirely sure if there is an alternative approach/way of dealing with this either, it seems as though module knowledge has to be shared but it does feel as if it's breaking the self contained, workable module structure.

Thoughts welcome.....

[avosalmon]

@boxxroom Thank you for watching the talk! I also got inspired by Luke's talk about actions and I think contracts in my talk can be implemented as actions as well.

To answer your question, yes, the order module is dependent on the inventory module. However, you can change the inventory module's implementation without having to change the order module since the order module only depends on the contracts (i.e. interface and DTO) of the inventory module. The idea is that modules are "loosely" coupled so that we can independently change the module's implementation as long as the contract remains the same.

An alternative approach is dispatching an event from a module and another module handles the event. This way, a module wouldn't need to depend on the interfaces and DTOs.