avosalmon / modular-monolith-laravel Goto Github PK

Hi Ryuta, Thank you for your awesome talk.
I would like to ask your suggestion on modularizing user module?
each user type can have one module? let say admin module, customer module and merchant module?
or all user type can be put on the user module and create one module for the role?

Btw, where do you put all common classes that are not binded/related to any modules like helper classes or utility classes?

Thanks a lot :)

Nice speak and thanks for sharing!

I got the idea about contracts between modules. But consider this scenario:

The Order module has a OrderLine product_id FK for Inventory and it is great interface usage on your example.

But, by “Laravel way”, to display an OrderLine with product names I would make OrderLine::with(“product”)->….

It would be a violation ? How do you deal with that ?

Hi! Thanks for an awseome Demo on laracon - me and my team will take a lot of inspiration from this in our works going forward. I just have a quick question that came in to mind when browsing the repository. The CartItem model inside the Order Domain references and foreging key relation in another domain (product - Inventory). Is this a bug or a feature? I'm curious since to me it seems that interface boundaries are violated?

Thank you for your presentation. I subscribed to your twitter account :)

I was wondering what if instead of developing modules apart, i can create package for every modules so that i can use them in my main application. This would still respect the domain boundaries ?

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.

"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.....