Posted by coreycoogan on June 5, 2009
I’m working on a project that is the epitome of BDUF. After more than a 4 week effort into an end-all be-all requirements document, the technical design phase has started. This requires the complete application design to be laid out with textual documents, Sequence Diagrams, Excel spreadsheets, class diagrams and countless other artifacts.
This is so ridiculous, as we all know that the second development begins most of those docs are out of date. I don’t mind doing UML docs, a little at a time, but doing all of them at once really sucks. I asked if there would be use cases, which I find to be the most useful artifact of all, but it seems they are meshed somewhere in the 70 page design document.
For those companies not quite willing to jump into a pure Agile methodology, may I suggest a hybrid between Agile and Waterfall.
- Define enough requirements to get the project going, i.e. most important features
- Design for those features
- Approve design
- Begin requirements on next phase during development
- Review development
- Make changes as necessary
- Start over
This is sort of like a bunch of smaller water falls, but at least there is some time to react to changes from the previous iteration, which could take any amount of time. It also breaks up the mind numbing Visio UML tasks so more attention can be focused to them. Whose to say that one week into the project, a better flow or object model won’t be discovered, invalidating all the sequence and class diagrams developed?
UPDATE (6/8/2009): Jeff Palermo wrote on this topic with some insights into how Headspring does Agile.
Posted in Architecture and Design | Tagged: Agile, Architecture and Design, Methodology | 1 Comment »
Posted by coreycoogan on June 5, 2009
The MVC project I’ve talked about in my first 2 posts is still moving along. I’ve continued to learn all I can about the new ASP.NET framework, but have a lot to learn. It’s very different (read:better) from the MVC I used to do 5 years ago in the JSP days.
As the rest of the team ramps up, I thought it was important to layout the application architecture. Being a fan and student of Domain Driven Design, I followed many of the patterns discussed by Evans, as well as others. The app requires a WCF service layer, so most the typical layering will reside behind the Service layer. We’re also using LLBLGen, with Linq, as an ORM. The client is anti NHibernate, so some other ORM had be chosen and in my opinion LLBLGen is the best database driven ORM around.
The app is an enterprise critical application and I’m trying to architect in a way that will support growth, foster SOLID principals and be easy to maintain. Here’s the layers we’ll be using, with a description of each.
app.web.controllers – has controllers for MVC.
app.application – DTOs, WCF service gateway, interface for WCF proxies. Controllers will take WCF service proxy interfaces via DI.
app.service – WCF service that sends/recieves DTO’s defined in app.application. Maps DTO’s to domain objects and interacts with the next layer to call Application Services.
app.service.application – application layer for the WCF service. Contains application services that act as a facade to the domain (core) layer. This is where all infrastructure and domain functions are coordinated.
app.core – where domain objects and repository interfaces live. This is where all business logic is essentially stored.
app.infrastructure – where the repository implementations live, as well as email gateways and other infrastructure stuff.
Posted in Architecture and Design, ASP.NET MVC, Design Patterns, Domain Driven Design | Tagged: ASP.NET MVC, DDD, Domain Driven Design, MVC Architecture | 2 Comments »