Decomposition in computer science, also known as factoring, is breaking a complex problem or system into parts that are easier to conceive, understand, program, and maintain
You could view decomposition as an integral part of design. Upfront decomposition could be viewed as modelling the code you intend to build. In advance, we can think about the design and classes we may want to have before we implement them. Code decomposition could be viewed as when we have written some code but we get the feeling it’s a bit clunky. Let’s say we have a method that has gone beyond 5-10 lines. This may trigger us to think that this method is too complicated and should be split into many methods. Or let’s say we have a class with 20 plus methods on it, that could trigger us to think more critically about the class and perhaps exploring breaking it into many smaller classes. That would be decomposition.
We can continue our PageObject example to think about decomposition. A common approach is to have one PageObject per page of our application. However, if you’ve got a very complex application such as a CRM, a single page could have a lot of functionality. If you modelled and implemented all that as a single class, it’s going to be a very large, complex class. Instead, we could break the page down into individual page objects and individual classes that are specifically focused on a subsection of the page.