We have an existing ERP system written in VB 6 that we are converting to .Net incrementally. Now, every module in the system is being separated into DLLs so that the product becomes customizable and flexible. I'm not sure if this is the way to do this.I think this will cost a lot of maintenance in the future. What do you think?
Program modules separated in different DLLs
.net;modules;dll
A DLL itself doesn't constitute a module design or improve flexibility. It meanly defines the state that the compiled source code exists in and is transported into the application.CustomizabilityUsually implies an API layer that allows developers to plugin additional functionality as either optional features, customer requested features or to separate feature development from application framework development.The ProsIsolation of source code ensures that a plugin developer doesn't make unnecessary changes to the application.Ability to load features on demand.Ability to expand the application over time.Clearly define boundaries between layers allow for different developments team with different skill sets. (i.e. a core team, a UI team and a features team).Different release schedules for the different modules can make meeting deadlines easier.The ConsTight coupling between plugins and application API can cause higher development costs when the API needs to change.The cost of implementing a feature can increase as the API layer has to always be adjusted to accommodate new requirements.The advantages of replaceable components is never utilized by the business. I see this happen a lot, where developers sing the praises of modular design but the business never takes advantage of it.The need to support the lowest common denominator. Rather than support the latest version of something like OpenGL. The application is stuck using an older version, because the API is too generic and improving the API is too costly.If different development teams create modules, then the application can suffer from having different user experiences for features.