Expected Design Patterns To Develop Modules?

[TheFerrettDeveloper]

I may be overthinking this, but:

We're considering using a module as a way of keeping business logics separated and code clean inside a larger products service - rather than having a huge entangled code base dealing with sales promotions, stocking logic, etc, we're hoping to use Modules to enforce some code separation.

But in many cases, we'd want to have at least some of the Modules information used in the "base" app - for example, if we're doing a generic products search, if we have Promotions separated into a Module, we'd surely want the search to return whether the item is on sale or not.

Initially, we thought we'd use code blocks to indicate whether a Module is enabled, and if so, to use the Module's functionality in the base app - "If the Sales Promotions Module is enabled, use this code." But the latest documentation doesn't seem to have an enabled()/disabled() to put in branching logic to say "If this module is enabled, run this code." And it appears that turning off a module doesn't fully disable code within it - if you have a service in the module and turn the module off, yet instantiate that service in an outside controller, that service still runs in the controller regardless of its enabled status or not.

So how are modules intended to be developed? Is the intent for Modules to operate like a WordPress plugin, where everything within a module operates strictly within the module, listening to events and never having any module-specific services instantiated outside the module itself?

Or if you are expected to instantiate Module logic/services from outside the module, how do you handle that hanging code if you disable the module?

If anyone's handled this in their own projects, I'd be curious to know how - and if the designers have structured Modules to work in a specific way, I'd ESPECIALLY like to know that.

Thanks,
T.F.

[TheFerrettDeveloper]

Any thoughts?

[dcblogdev]

BTW the latest docs are now located at https://laravelmodules.com/docs/v10

I like the idea of code separation using events and listeners but in practice, I haven't done that and had coupling within the modules. For example, if I have a Purchase Order that will refer to models from Users, Customers, Products, and Suppliers to build up the queries.

I tread modules like core classes but separated into modules.

You can wrap code from modules to ensure they are enabled before running like:

if (Module::isEnabled('books')) {
    $books = Book::get();
}