The Ship Layer can hold some business logic?
Soufraz opened this issue · 5 comments
We are in great doubt here in the company in the implementation of this architecture. Firstly, I would like to congratulate. It's very cool to have such a well-defined line to follow. Congratulations!
Our question is about when it is acceptable for business rules to be within the Ship Layer. Some examples:
- We have several routes in the system that can only be accessed if a company has been saved in session.
- In every change of route we need to check whether it has new messages or new warnings from other users of the system. Like a notification center.
- In every change of route (again) we need to check if the user data fields is completed and alert to the logged user that he needs to fill this data asap.
We understand that these are global resources that can be accessed from anywhere in the system. Would that be a reason why they were inside Ship Layer? On the other hand, in the case of messages and the user data, we will have a Message Container and a User Container. Soon I imagine that this feature of checking new messages should be in their Containers in order to get everything in the domain place.
Would you suggest us a clear way of thinking when deciding if something business could be inside Ship Layer or in Container?
Thank you very much in advance.
Hey there.. just from an "implementation point of view" i would implement these "checks" within a middleware (e.g., in laravel)
The Ship itself holds "code" (models, tasks, actions, ..) that is shared across all containers - so basically you can put whatever you like there..
I think that "whatever I like" is a very delicated phrase to use in this case. Look to apiato. Even localization, user and authorization that is shared accros all containers is under container layer.
yeah, but you could move the LocalizationMiddleware to the app/Ship/Middlewares folder and use it from there.. As the Localization container provides additional features, the middleware was placed in this container..
porto - at least for me - is more like a "go to strategy".. it can give you some basic ideas on how to structure your application - but you can always bring in your own style..
There are times, where you put files (tasks, models, middlewares) into a container, but later think, it would be better to move it to the ship layer.. but you can do it.. it is not "written in stone".. just go for it..
@Soufraz nice question, the short answer is "you should never write business logic in the Ship Layer, that layer can only hold technical details (things that aren't shared with the domain experts "whoever gives you the requirements") e.g. hashing mechanisms, UUID generators, some PHP magic.. The containers on the other side should NOT hold these kinds of functionalities (Mid-level code) they should instead only contain pure business logic.
On the far side as @johannesschobel mentioned, if you feel that a particular peace of code should go in a place that doesn't make much sense within the overall architecture, but it serves your code pretty well there, then got for it, nothing wrong with that at all if it's documented and under control.
I hope that helps and excuse my delayed answer.
Thank you @Mahmoudz and @johannesschobel. Very clear now.