2
I'd like to hear what you think about this...
I'm working on a new architecture for an existing software product. I want this to be a flexible - and especially extendable - architecture for future modifications. I've been researching best practices artices and seeking advice on the proper way to architect the product.
Right now, I have the architecture broken out into the following layers:
- UI / UI Process layer
- Process Service layer
- Business Process Service / Business Objects / Persistence Objects layer
- Data Persistence (database) layer
You may notice that Microsoft's architecture guidance notes played a large part in the direction I've taken.
While this seems appropriate, it almost seems like overkill for my project. Many of the reasons an architect would include some of the components of these layers just aren't applicable (at least not currently) to the project. Don't get me wrong - I'm sure all of these layers will still exist to some extent - except for possibly the Process Service layer (right now primarily a pass-through layer), and some components of the Business Logic layer. So I'm trying to decide whether to scale the design back and streamline the code, or leave much of the code in place for future modifications. If we never make such modification, I've wasted a lot of time coding and maintaining 'pass-through' code. On the other hand, if I streamline too much, I may lock myself into a architecture that isn't flexible to handle future requirements without a lot of work (I know it isn't possible to design a product up-front to handle ALL future requirements changes, but I'd like to plan ahead as much as possible).
So, what do you think? Leave it, scale it back, or half-and-half?
