Local initiative driven by Microsoft - Spain
See feedback from the community who have used this Guidance since many months ago:
http://microsoftnlayerapp.codeplex.com/discussions/229559 http://microsoftnlayerapp.codeplex.com/releases/view/56660#ReviewsAnchor http://microsoftnlayerapp.codeplex.com/releases/view/49514#ReviewsAnchor
Project Scope
This project/sample is willfully restricted to
.NET implementation of most used patterns in N-Layered Domain Oriented Architectures based on simple scenarios easy to understand (Customers, Orders, Bank Transfers, etc.). This initiative is NOT trying to teach how to apply DDD. That shouldn't be Microsoft's goal and DDD is much more than Architecture & patterns implementation.
This is an Educational example, not a real world system, it shows
educational scenarios, easy to understand useful from a
patterns implementation point of view, but not necessarily as a whole business application. The architecture is decoupled and relatively complex so it would allow to grow your system.
Also, this sample
goes along with our Architecture Guidance, and there are aspects in the guidance that are not covered by this sample, and viceversa.
Its
main goal is to show how to use
.NET 4.0 wave technologies implementing typical DDD patterns:
N-Layered Architecture, Domain Entities, Aggregates, Repositories, Unit of Work, Domain Services, Application Services, DTOs, DTO-Adapters, etc.
Reminding what DDD is and what this project is NOT covering
Domain Driven Design is much more than Architecture and Design Patterns. It implies a specific way of working for development teams and their relationship with Domain experts, a good identification of Domain Model elements (Aggregates/Entity Model, etc.) based on the Ubiquitous Language for every Model we can have, identification of Bounded-Contexts related to models, and a long etcetera related to the application life cycle that
we are not covering (only very slightly in our Guidance). There were already excellent literature and knowledge about that before this project was started, coming from people like
Eric Evans, Martin Fowler, Udi Dahan, Greg Young, etc.
Our guidance and sample application
focuses only on about a 20% of DDD subjects, we do NOT intend to teach DDD as a whole", we are only
filling a gap we saw regarding
implementing most useful Domain Oriented design patterns with the latest version of .NET.
And remember that we need you; we need your
constructive feedback to evolve and improve this project.
Thank you very much.
New! First V2.0 ALPHA version and preliminary chapters’ drafts
Dear colleagues, after some time of effort, we can show you our preliminary version (alpha version, actually) of what V2.0 will be. We are initially covering mostly ‘the server-core’, with a single client app consuming it (Silverlight), and evolving and taking into account many experiences we got and learned also with you. We got a lot of feedback coming from our Discussions-Forum at Codeplex, and many other channels. Many of you have already used this project as a reference and have applied it into real & complex projects, with success in most of the cases, and this is the best reward we could get!. But also, we got many points we could improve. Any constructive feedback is important and will be taken into account. We’ll continue working and evolving it in order to get better patterns’ implementations, along with you.
Improvements in the Domain Layer- Using
EF 4.1 POCO Code-First approach for
Domain Entities/Aggregates/ValueObjects- Added more Domain logic within entities (no anemic domain)
- Better exposure of Aggregates’ elements
- Better support to navigations between Aggregates and elimination of inverse relationships not needed
- Entity Validation support
- Specification pattern implementation, use of expressions as specifications and composition support
Improvements in the Application Layer-
DTO and DTO-Adapters support- Validation support
- Improvements in exception management
Improvements in the Data-Persistence-Infrastructure Layer-
Using EF 4.1, CodeFirst, DbContext- Persistence layer simplification and improvements
-
IoC/Unity: Elimination of abstractions no needed- Better testing strategy for Integration Tests
Improvements in the Presentation Layer- Reviewed and minor improvements in MVVM code.
In current V2.0 version we only support a Silverlight client. We'd like to add more clients in the future.
Improvements in the Distributed-Services Layer- Segregation in 2 Web-Services (One per MODULE).
-
Improvements regarding WCF exceptions handling (less spread code in Catch)- We currently use SOAP Web-Services, but we will switch to
REST in the coming future when the new
WCF Web API (WebApi.all) (still in beta) will support
Silverlight.
Here you can get preliminary main DRAFT chapters for V2.0 (Second Edition) currently being reviewed, not finished.
http://microsoftnlayerapp.codeplex.com/releases/view/69008#DownloadId=253553 You can also download the first edition of the Arch-Guide eBook (free), but take into account that it is related to V1.0 of this project.
http://msdn.microsoft.com/es-es/architecture/gg189193
Architecture Diagram
| Architecture-Technology Diagram |
|---|
 |
Required Base Software _
- Microsoft Visual Studio 2010 - Microsoft Expression Blend 4 - Microsoft SQL Server 2008 R2 Express (or higher) - Microsoft Unity 2.0 - Microsoft PEX 2010 - Microsoft Silverlight 4.0 Toolkit - Microsoft Silverlight Tools for VS.2010
Silverlight 4.0 Client
| Customer List | Silverlight Transition |
|---|
 |  |
| View Customer |
|---|
 |
It is very
'Domain Oriented' , therefore, it illustrates typical
DDD patterns , like
Domain Entity, Value-Object, Aggregates, Repository, Unit of Work, Specification (most of those patterns originally defined by
Eric Evans and
Martin Fowler ), but implemented using ADO.NET
Entity Framework 4.0 , Unity, WCF, and PEX (Stubs and Moles) for Unit Testing and mocking.
DDD is much more than this!!
We're talking about complex apps…, all their business rules (Domain logic) are points that, in most of the cases, need to be changed quite a lot during the app’s life. So it is critical to be able to change the app and test it in an easy way and independently from infrastructure areas (technology, data stores, data access technolgies, ORMs, etc.). Because of that, it is important to have the Domain/Business Layer (domain logic, entities, etc.) decoupled from the other layers.
Having said so, in our opinion, the best actual architectural style that fits with those requirements is a
Domain Oriented N-Layered Architecture which
is part of
DDD (Domain Driven Design). And
this Sample-app is showing a way to implement a Domain Oriented N-Layered Architecture.
But, and this is extremely important, DDD is on the other hand, much more than just a proposed Architecture and patterns. DDD is a way to build apps, a way for the team, to work in projects. According to DDD, the project’s team should work in a specific way, should have direct communication with the Domain Experts (the customer, in many cases). The team should use an
‘Ubiquitous Language’ which has to be the same language/terms used by the domain experts, etc.
But, all those ways to work are not part of this Sample-App, because it is process, kind of ALM, so,
if you want to really “Do DDD”, you’ll need to read Eric-Evans' book or any other DDD book where they talk about the DDD process, about the project and the team, not just the Architecture and patterns. Architecture and patterns are just a small part of DDD, but, in this case those are the points we are showing here (DDD architecture and patterns).
But we want to highlight that DDD is much more than Architecture and design patterns.
The Team
This project is locally supported by several Software Architects and Developers (coming from Microsoft DPE Spain, MVPs, partners (especially Plain-Concepts) and Microsoft Services).
We'll be happy hearing from you and getting your feed-back to improve and evolve this Architectural example!!.
Regards,
Cesar de la Torre
Architect – Development & Platform Evangelism (Spain)
Microsoft