Do you consider OOP, Agile, UML, design patterns usage as a threat?

Now days we have many ways to design framework or architecture for software project. Software company’s uses object oriented methodology, agile process, Design patterns, UML etc. in order to design the base of project. Agile method basically used for emergent architecture in order to gather requirements and complete development cycles, and that’s the threat for the developers and project stakeholders. For all the processes we use diagrams, models to represent the overview and flow of the system. A major success factor associated with agile methods is the resources that are going to work on the development team. Sometimes developers do not maintain the customer and stakeholder expectations and requirements well, and those conflicts affect project success. Same kind of threats associated with UML and design pattern uses.

UML forces to determine ‘what’, ‘why’ and ‘how’ to design the system, but it’s always ambiguous to explain ‘why’ in the document, as the business requirements always used to be changed, it impacts on the architecture and design. During the initial process it’s crucial that the development team and the clients come to an agreement as the on paper based model system that they are going to build. It’s always hard to get tuning between developer team, designers and clients.

And when we think about design patterns, experts always suggest the use of design pattern for an enterprise level application. However, the successful implementation demands development team should be wise enough to work on design pattern that finalized. Sometimes happens that the team members are not comfortable with the technology or the design, which affects the project success.

In anyway, I like the design pattern terminology and different ways to implement the system.

Persistent Domain Objects Pattern

It provides a greater flexibility for the enterprise level applications. Benefit of this architecture is that we have to only change the DAL (Data Access Layer) when we change Database (i.e. to make other layers independent of Database), (and of course this depends on whether the changes are syntactic or semantic – if there is considerable semantic change, additions, (new tables, new fields)the applications change) and it allows to persisting domain objects Other advantage is that unit testing of each layer can be done separately. Also this architecture decouples the application and makes it more flexible. We used the same pattern in one of the project, below is the description for the same:

1) DAL (Data Access Layer): This layer retrieves the data from database.

2) Interface Later: DAL must implement interface layer to make sure that all required methods are implemented by DAL. This is very important when we have multiple DAL (i.e. when we have multiple databases).

3) Factory layer: This layer returns the object of DAL.

4) Business Layer: The business logic is implemented in this layer. This layer creates objects of DAL using Factory layer.

5) Presentation layer: This layer dealt with presentation of UI and binding of data with UI.

This Pattern gives a solution to separate and deal with the tight-coupling of the persistence and application logic code. It decouples both layers by extracting the details of the persistence implementation along with hiding it behind an interface.

Reference - Previous projects