Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Abel Avram on Mar 16, 2009
In this article Billy McCafferty presents S#arp Architecture, an ASP.NET MVC architectural framework meant to leverage current best practices in architecting ASP.NET web applications by providing a project code template which uses Domain-Driven Design techniques and has built-in support for NHibernate, Castle Windsor and SQLite.
Read: A Fusion of Proven Ideas: A Look Behind S#arp Architecture
McCafferty starts with a review of current trends in web applications architecture design: abstracted infrastructure, loose coupling, TDD and DDD. He outlines some of the lessons learned by the software community as the foundation for S#arp Architecture.
S#arp Architecture offers a project code template which uses the following frameworks and techniques:
- The Separated Interface pattern, in conjunction with the Dependency Injection pattern, for removing concrete dependencies on a data access layer from the domain and controller logic;
- The Repository pattern, for encapsulating data access concerns within discrete classes adhering to the Single Responsibility Principle;
- The Model-View-Controller pattern, realized with ASP.NET MVC, for introducing a clean separation of concerns between the view and controller logic;
- NHibernate, and its Fluent NHibernate extension, for removing the need to develop and maintain low level data storage and retrieval coding while keeping the domain in blissful ignorance of the persistence mechanism;
- Common Service Locator, with a default of Castle Windsor, to provide a loosely coupled means of interacting with the developers preferred IoC container;
- SQLite in-memory database for running behavior-driven tests versus those that emphasize integration with a persistent database;
- Visual Studio Templates and T4 Toolbox to generate project infrastructure and common CRUD scaffolding for each domain object to remove hours of redundant and tedious coding.
S#arp Architecture is currently an RC2 release targeted at ASP.NET MVC (RC2) web applications and uses NHibernate 2.0.1. A final release is to come soon.
Visual Studio vNext: ALM features for Agile Planning, Team Collaboration
RDBMS to NoSQL: Managing the Transition
Troubleshoot Java/.NET performance while getting full visibility in production
i wonder where REST and Messaging fit in that architecture ?
I hope someone can make a explanation ..
thank you
Hi Welly,
S#arp Architecture does not dictate the use of a particular communications approach. In other words, you can use RPC, REST (MvcContrib's for example), WCF, Web Services, etc. We're currently writing some sample pages to demonstrate how a couple of these approaches are supported.
Thanks a lot Billy for replying,
Do you think it's necessary to separate command and query in that architecture ?
And i hope you don't mind to give a comment about my approach here.
In our current approach we have a different application for Services and Web. So the Core, Data and Application Service is different application from the Controllers and Web. In application layer we have WCF REST service.
Web application call the rest service with jQuery. Do you think this approach is appropriate ?
Your article said that we can't be an expert if we're not make a mistake. So i'm hope you understand if my approach is wrong. :)
Thank you very much again Bill.
First of all I really liked this article as it nicely summarizes the development landscape today.
You wrote this:
A major tenant of DDD is placing the behavior of the domain within the domain objects themselves. For example, instead of having a separate CustomerAccountLogic class to determine if a CustomerAccount is up to date on payments, you would simply ask the CustomerAccount itself for this information. In this way, the behavior of the domain is embedded into the model itself.
This does not accurately reflect what Evans wrote in Domain Driven Design (the book). He specifically distinguishes between code which belongs in an object's class, and code which belongs in services (which could in fact be something like a "CustomerAccountLogic" class). Operations which affect multiple different types of objects are implemented not in the object classes themselves, but rather in these service classes (which are still part of the overall domain model). It's right in the diagram on the inside cover of the book!
Also, to be really pedantic, you meant "tenet", not "tenant".
This is a great point to bring up Steve. In DDD, there are certainly domain services in addition to domain objects themselves. The intention behind my description was to inform readers that domain logic does not need to be completely separated from the model itself; that the model encapsulates behavior as well as data. Readers should certainly read Evans' DDD book for a more complete discussion of the implications of a DDD and where to draw the line among various DDD components. (And thanks for the spelling heads up!)
I recently saw two interesting discussion on that distinction between code placed into BO (domain) classes and code placed into services. basically, that's right: if a code operates on a domain class only, it is normally placed inside, if code depends on many domain objects or an external service it is better to be placed in "business logic" service classes. Those service classes still call methods of domain objects if necessary: www.infoq.com/presentations/Making-Roles-Explic...
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
Andrew Watson talks about the work of the OMG, where CORBA is alive and well (hint: in your car), UML and UML Profiles vs. custom Modeling languages, DDS and other middleware, and much more.
Sohil Shah discusses creating iPhone and Android enterprise mobile applications based on cloud services using the open source platform OpenMobster.
Paul Sanford presents the transformations supported by data throughout its life cycle, and how that can be better done with Splunk, an engine for monitoring and analyzing machine-generated data.
A common “best practice” for unit tests is to only write a one assertion in each test. I intend to question this advice by showing that multiple assertions per test are both necessary and beneficial.
John Rauser presents the architectural and technological evolution of Amazon retail websites starting with 1994 and ending with adopting Amazon Web Services.
Michael Stal discusses system architecture quality, how to avoid architectural erosion, how to deal with refactoring, and design principles for architecture evolution.
Every developer has had to integrate with another system, API or component. Tis article provides strategies to handle the change and for he separating system boundaries.
6 comments
Watch Thread Reply