In our company we have to follow a rigid cycle of:
- Requirement Analysis Document(Use Case Document).
- Design Document (first High level then Low level)
- Coding according to the document.
- Unit Testing.
- QA team then does testing
It all started when we developed a component in the initial lifecycle of project. The component consisted of its own domain layer/business layer, data layer, interfaces ... etc.
After say around a month we had to create a new component due to some other given requirements, it also consisted of its own domain layer/business layer, data layer, interfaces ... etc.
There is a Common Component in our solution where we keep all common methods/classes in the entire solution.
We kept on developing second component as the requirements were coming and we were providing new features in that component, as a result the design also started evolving in this component.
The first component was kept untouched, with old design. There were however some classes/interfaces that were mostly similar but duplicated violating DRY.
Is it ok to just add reference of the business layer, data layer or "other relevant components" of Component2 in Component1, does this approach adhere to any architecture/ software design best practices?
The common classes/methods should be promoted to common component where they could be used by other components (following DRY principle)?
With first approach it seems that my component/ solution will be in a danger of Big ball of mud.
With second approach it seems that if a class is used in more than one component it should be promoted to Common component. Doesn't this violate High cohesion principle
So, long story short I am asking for any expert advice on the two mentioned approaches or may be another one from software professionals/ architects. Since this is a common problem which every software product faces, so how to tackle it?