How far do I break down individual tasks within a typical scenario of Web application reacts to user input?For example, in the case below, say a scenario is User submits a form, causing user data to be turned into an Object (technical detail) and then saved into the database .I am asking, if by continuing to separate individual concerns I come across, into various classes, services, and methods, am I making things harder for myself or future maintainers in the long run?  BrieflyTo put it very briefly, do I continue to move handling of individual code-paths (such as filter data, organize data into an object, receive data, save data into database, send data to view, etc) further down, or do I merge and combine them into a single action?  For example, I could write a single class to read and assemble input, filter it, and put it into an object, and then have that object be returned to Controller, for saving.  More BrieflyEven more briefly, am I creating too much wiring inside my Controller where I pass too many things back and forth (example below where I pass variables such as $inputData, $filteredData, $domainObject)?  Should I be creating less?Brifier?Skinny Controllers, Fat Models ... My Controller is not skinny.  How do I make it skinnier?Exampleclass CustomKitController extends KitController{    function save()    {        // get Position and Item for new line numbers        $linePlacement = $this->repository->getNextLineNumbers($this->orderId);        //get input from POST        $input = $this->input->getCustomKitInput($_POST);        //retrieves a kit template from database by model        $kit = $this->repository->getKitByModel($input['kit_model']);        //creates a Item for the database        $salesItem = new SalesItem();        $salesItem->setUnitprice($input['kit_price']);        $salesItem->setDescription($kit->getDescription());        $salesItem->setMultiplier($input['kit_multiplier']);        $salesItem->setQuantity(1);        $salesItem->setSalesorderId($this->orderId);        $salesItem->setUnitSystem('');        $salesItem->setPosition($linePlacement['position']);        //save customized Kit template to persistent storage        $parentItemId = $this->repository->saveLineItem($salesItem);    }}Example of What I'm asking:Looking at the code above I am thinking there are too many lines about $salesItem.  So I can refactor it like so:$salesItem = $this->factory->createSalesItem($input, $kit, $linePlacement, 1);and create somewhere the Factory that builds and populates the SalesItem for me and that takes the $input, $kit, $linePlacement, 1 as parameters.  Those parameters is something I call wiring.  They are the data wires that make the connections between various pieces of code.And I can call the Factory a code construct.  I have several code constructs already in my example.  They are:$this->input->... (receives and compiles input)$this->repository-> (database operations)$this->factory-> (would be the new one just mentioned to create SalesItem)And the wiring will have to flow through them, from input, towards repository, some input will go into Factory, so wiring has to go there too.My question is about how to find a healthy medium between wiring and code constructsI can avoid passing the wiring around by not using the code constructs.  There will be nothing to pass the data wire through, it will be a single block of code from input to output.  But then I try to abide by Separation of Concerns.  I want my Repository wants nothing to do with where the input comes from, but wants to just retrieve or save, or look up information.So I can keep breaking down my tasks and doing something likeReceive initial wire ($this->orderId), feed it into repository to get line placementUse POST to Retrieve InputRun Input through Repository to receive Kit TemplateUse three wires of Line Placement, Kit Template, Input Data wires, feed them into Factory (or not) to produce the Domain Object of SalesItem.Feed SaleItem to Repository for storage.Question:What are templates, guidelines, recommendations for making decisions about whether to create certain code constructswhether to place certain code constructs inside other constructsIn order to minimize (or better yet, find a happy medium) for the wiring that is passed through them, connecting everything together.This question reflects my concerns about parameter passing, (aka wiring), between various code constructs.  I can cheat and merge some code constructs at risk of breaking SOC and SRP, or I can creates a mess of wires running everywhere while maintaining SRP.  Is that a thing of concern?
Save Custom Product Kit using Web Application
php;object oriented;design patterns;mvc