MVC + WCF + TDD or DDD architecture [closed]

Question

Here we are again at the crossroads.

i want to try to implement, at least for the next 3 years, a simple, proven way to architect my applications. Every time i am going to start a project it feels like it's the first time because of the overwhelming number of "ways" to create websites these days.

i have this sample code i got from this package i purchased call Design Pattern Framework 4 C#. Among the multiple projects they have, there is one, which is called, Design Patterns in Action. You can download it from here https://skydrive.live.com/redir?resid=B853B0DB724C30E5!16735&authkey=!AOeHSAWa_P4vzzU

My question, after you take a look at that solution, What's good, bad, what would you keep, what would you remove, what's unnecessary, etc etc. about this example?

I understand they are trying to show multiple clients and also multiple DAOs. But overall, would this architecture be one that you would take as a "template"? Thanks.

Answer 1

System Architecture is much like building architecture:

• There is not one "right" way
• Everyone has their own opinions on the "best"
• The "best" architecture depends on the context and needs
• Styles and methods change over time

There are many factors that go into choosing an architecture:

• Time to Market - how long do you have to get something going?
• Maintainability - will you be the only one maintaining it? Open Source?
• Extensibility - will it be a closed or open system?
• Scalability - simple utility or enterprise-scale?
• Platform - web or native? Desktop or Mobile?

All that to say I'd be surprised if you could come up with one all-emcompassing framework that fits every project you're going to have for the next 3 years. Think of MVC, WFC, TDD, DDD, etc. as tools that you can use to build the right a system that meets the needs of that situation.

My opinion is: use whatever concepts you can understand (and can teach others if necessary) as long as it fits the particular situation.

Answer 2

My question, after you take a look at that solution, What's good, bad, what would you keep, what would you remove, what's unnecessary, etc etc. about this example?

After a quick look, here's what I'd say :

• With regards to the DDD tag on your question, this is clearly not a domain driven architecture. The business objects look anemic apart from a few simple validation rules and many of the basic building blocks of a DDD architecture aren't present (aggregates, value objects, etc.)

• Unless I have missed something, most business operations are CRUD operations which is not really representative of a real-world enterprise app.

• There's a fat Service layer with a fat ActionService class which basically seems to handle all the use cases of the application. The good news is, it deals with the uses cases in an agnostic way (as far as I can tell, the Request and Response objects it manipulates are delivery mechanism independent). Being fat is less desireable, as the class includes too many responsibilities (SRP).

• Using Repositories on the client side and DAOs on the server side seems weird, but why not.

• If it's really test-driven, why not include all unit tests instead of just one sample ?

Apart from that, the layers are well designed and, as the multiple presentation layers show, it shouldn't be difficult to substitute one front-end for another or one persistent store for another.