One of the first major deliverables produced by the patterns & practices team is Application Architecture for .NET: Designing Applications and Services. This guide is now getting close to 5 years old (it was written by Ed long before I joined the team), but unlike some of our other early deliverables, we've found that it's still surprisingly popular for its age. This is probably partly due the fact that the guide is written at a sufficiently high level for it to still be relevant despite the changes and advances to the platform.
Even so, we've decided that this guide is now due for a refresh, and we'd like your help in figuring out which direction we should take it. In addition to the changes in the underlying platform and in the industry's understanding of architecture, the patterns & practices portfolio has evolved significantly, and we want to be thoughtful on what type of content should go into an updated Application Architecture guide and what content should go in other places such as software factories or Enterprise Library.
Feel free to send us any weird and wonderful ideas you have for the next version of the guide, but to get you thinking, here are a few questions that are on my mind:
I'm quite excited about finally updating this guide, and we're looking forward to your perspectives on what it should be.
That document was very useful to us!
- you can't assume a SOA frame. Other architectures are needed. Choosing an architecture that match application/enterprise requirements is still a first step...
- suggestions as to p&p usage in relation to specific architectures
- when (and NOT) to use specific architectures and why
- also keep interoperability as an important goal for some systems/architectures. EAI/BPM/Workflows are important but we also often end up with complex systems that MUST interoperate witn N other systems (other languages, others oses, very legacy stuff sometimes, etc.).
- not forgetting basic scenarios (client/server is still sometimes the best solution)
The document should be broken down in:
a) high level architectural concepts (pros/cons/when-to/when-not-to, etc.)
that part can be fairly static and updated rarely
b) implementations details
that (thoses) part(s) could be updated more frequently without forgetting that enterprise applications are not rewritten with each .NET release and much age gracefully
covering proven practice is necessary but exploring emerging architectural standards is also very important. Everything is changing so fast (again:-) )
Some architectures are a bit too much pattern happy but end up being complex to maintain, implement, etc. Simple (design) is beautiful:-)
Try this on for size...
1. short catalog of common app designs, and what pieces/areas/domains/layers they have
2. Drill down into each one, highlighting key patterns and alternative designs for each area.
3. pointers to p&p and other materials that make those design concepts real in code and technology
does this sound like a good idea?
Ed, this would work out fine. Exactly what we are typically looking for. I feel the current guide is also a bit short on the business layer side of the story. When business workflows, how business entities (suggestion: include the passing entities through tiers paper), business logic, what goes where... This is true also for the p&p deliverables btw. Although some of the factories do a pretty nice job.
And of course, make sure to connect to the Software Factories vision.
I've actually just come across a hard-copy of "Enterprise Solution Patterns Using Microsoft .NET" (http://msdn2.microsoft.com/en-us/library/ms998469.aspx) version 2.0 (published in 2003).
It surprised me a bit (in a good way :-) ) that it was also still quite relevant these days and it might be a good candidate for an update as well...
1. We use the guide during our technical architecture stages. Once the application style is recognised, we use this guide to help us in laying out a initial application architecture.
There is missing pieces from a SOA prespective.
2. Yes, there are relevant, but the underlying implementation technology has drastically changed. So you need to update it to have .NET 2.0/3.0 into considerations.
Also, address the various security models applicable to a enterprise application architecture.
3. you should give hints on how to use the implementation techonolgies like Service Broker, ORM using NHibernate, ADO.NET vNext/LINQ, UDDI Services in SOA, MSMQ etc... along with mapping them to the design patterns.
4. SOA is no doubt a proven application architecture and integraion sytle today. the guide should address SOA and SaaS kind of applications.
5. as the SFs and Entlib are popular, most of the .NET developer and Architects community are aware with these frameworks.
6,7. the guide should address application styles like CAB/smartclients, OBA, ASP.NET 2.0 + AJAX, Composite Services.
8. Yes, the guide should cover new technolgies like parallel processing capabilities, Multi-threading, Service Agents and BPM solutions.
Also, please update the integration patterns and data patterns guides as well.
P&p is not limited to MS's p&p. There are some excellent frameworks out there that make use of .NET technology and can easily be mixed with application blocks, etc.
We use CSLA (http://www.lhotka.net/Area.aspx?id=4) with CAB, DAAB, etc. CSLA is an excellent example that is being upgraded to leverage new MS technologies without breaking old code. It is 100% pure .NET and source code is freely accessible in C# and VB. It is very important that enterprise apps be maintained and upgraded easily. We switched from Remoting to WCP in nothing flat because CSLA is architected correctly. Next update supports WPF, among other things.
There are other good examples out there. These examples are real world examples that developers can download and learn from. Mentionning those real world examples with the pros & cons of each would also be valuable.
> There are other good examples out there.
Can you provide some links to these "good examples" that you consider of real world examples?
Hi guys!. Nice to know a new release will be available. We are now taking the current guide as the bible for architecturing ...
what i would like to see on next release are:
- more about CrossCuttingConcerns such as Exception management
- offline capabilities (ie. smartclients)
- more on implementation based on current platform such as WCF and WF
- more on security, i.e. considerations on how to exposing and consuming services through WCF, if ssl, ws-security, and so on.
- concepts of composite applications and how different technologies could be integrated
- integration scenarios (i mean, different scenarios where biztalk, wcf, wf, sssb, etc is more appropiate)
- best practices for architecturing ... sth like a sheet to have on your desk and see every day.
- tips for architects that not precisely are technicals .. some tips regarding to communication, sth like perspective model.
- guidance for
thanks, look forward from news ..!
Since there are several other books that need an update and that you have more experience with the patterns, I suggest you:
- Focus on the scope of the first book.
- Update the patterns by:
1- Simplifying them.
2- Removed the not relevant anymore.
3- Replace with new patterns.
- Have a reference application that uses the new technologies
No we're not going to ask you any questions about your age, race or income. This is an application architecture
This document proved to be of great help back in the days. I think we as developers have been playing catch up on Java in regard to how we organize business (domain) logic in our applications. This article explains my observation in more detail http://www.paulgielens.com/archive/2006/08/08/Organizing-Domain-Logic.aspx.
I would like to see this whitepaper evolve in this direction. Perhaps even take the advancements in LINQ, Entity Framework and LINQ to SQL into account.
1. These days never.
3. Patterns seems like a good approach to me..
4. Certainly, though perhaps a seperation between application and enterprise architecture could be useful in the book.
7. Domain driven and model based are the ones that I'd be most interested in (at the application architecture level).
8. Both should be covered.
Eds idea above seems like a good approach.
It's long overdo, but we're kicking off a project for v2 of the patterns & practices Application
Buenas, uno de las primeras guías de lectura obligada de la gente de Microsoft Patterns and Practices