Steps to Architecting a Solution
Is there a definitive set of steps you should take to architect a solution? For instance, start with the use cases to determine the data that needs to be stored and their relationships, build the database, design the DAL, BLL, Service Interface, etc, etc. I've ready many object oriented design books, but none of them seem to state where to start and how to work your way through the process until you have a solution.
Daniel Hicks, Mar 07, 2011
Daniel, This is a good questions and I would like to share some of my experience. The high level steps are pretty well defined and may wary based on what approach you take. I am just putting it down what comes to my mind at this point in time.
For example are you designing Database first OR objects first? Your approach may wary somewhat but the process remains the same. And nowadays with the gaining momentum of TDD/BDD and even DDD things fall out of place. What I do is as follows?
Assuming requirements are gathered and usecases are built, I usually take the following path.
- Build the overall system diagram (very high level) including external components if identified.
- Build the database logical diagram based on the domain and usecase study
- Build the object model based on the domain and usecase study (This may vary depending on scenarios and context)
- Identify services
- Identify existing framework for services (like NServiceBus, Agatha Request Response Layer etc).
- Identify DAL components (evaluate whether any existing framework fits the need like enterprise data block, EF, Repository pattern etc).
- Security and Authorization (along with the required granularity, whether role based or custom)
- UI pattern (MVC, MVP or MVVM)
(For webforms and windows forms I go with MVP, for WPF I go with MVVM). For brand new web projects my recommendation would be to go with ASP.NET MVC.
- Exception handling and production support strategy
- Logging and Health Monitoring (evaluate existing framework or design a specific one based on some existing framework or library)
- Dashboard for log analysis (evaluate existing framework or build as required)
- Configuration management
- Deployment strategy.
- Server Monitoring (nagios etc).
For non functional requirements
- Performance numbers (based on discussions with the clients and estimated loads)
- Scalability and extensibility (this may have an impact on the architectural decision)
All the above decisions should be made upfront. This is not a comprehensive list but the most common which I use.
For application development (identify early what things are required):
- I usually prefer a TDD/BDD approach wherever possible, because not everyone is comfortable with this. (But this should be highlighted upfront as this has impact on timelines)
- Testing strategy and tools. For e.g. for UI testing I prefer WatiN or Selenium along with Moq or RhinoMock for mocking, MBUnit/NUnit/MSTest for unit testing.
- Development environment and tools including browser like firefox along with plugins like yslow, firebug, web development helper etc.
- Code analysis (fxcop/stylecop)
- Tools to monitor network traffic like fiddler, tcpmon etc.
and much more..
Definitely all these things will be finalized based on discussions with various stake holders, but the more you can identify and put it during this stage the better it gets.
Rajesh Pillai, Mar 08, 2011