Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In our company we have to follow a rigid cycle of:

  1. Requirement Analysis Document(Use Case Document).
  2. Design Document (first High level then Low level)
  3. Coding according to the document.
  4. Unit Testing.
  5. QA team then does testing

Abstract:

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.


Question:

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?

Or

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?

share|improve this question
1  
The design documentation should be your unit-tests. Refactoring should be a standard part of your development process. –  Matthew Dec 12 '13 at 21:54

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.