Published first ALPHA version of Domain Oriented N-Layered Architecture V2.0


UPDATE (Dec.2013): The sample application can be downloaded from here: http://sdrv.ms/18bjaba

The last chapters can be downloaded from here: http://sdrv.ms/18bjLty

First V2.0 ALPHA version at CODEPLEX and preliminary chapters’ drafts of eBook (Second Edition)

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

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://http://msdn.microsoft.com/es-es/architecture/en/

V2.0 ARCH_IMAGE_FOR_CODEPLEX

I would also like to remind the following (Project Scope and main Goals and what we are not covering):

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.

Feedback and Improvements

Remember that this is a very early version (ALPHA and preliminary eBook Guidance drafts). We are, in fact, getting quite a lot of feedback and therefore refactoring many points & code that we acknowledge are improvable. But you can actually get the essence of our approach.

We’d really appreciate any constructive feedback in order to improve our current arch-guidance and sample-app.

See feedback from the community who have used this Guidance (V1.0) 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

Comments (8)

  1. Tom Pester says:

    Hello Cesar,

    I'm looking forward to see how this project evolved in V2 cause I thought V1 was already good.

    • Added more Domain logic within entities (no anemic domain)

    Some of the code in V1 was indeed quit intemate with the domain objects and this was a sign that the domain was anemic. Intemicy between objects is not recommended :)

    • Better support to navigation between Aggregates and elimination of inverse relationships not needed

    I know Jimmy Nilsson also advocates this. What is your reasening to remove them. Just cut of the unneeded complexity and unnessary maintanance?

    • DTO and DTO-Adapters support

    This one does not surprise me although I still think its justified to use domain objects in the presentation layer if it doesn't hurt evolution of them on both sides.

    This is quit debatable but a Person in the domain is still a Person in the presentation excpet that it doesn't have behaviour. Why can't a Domain object be considered a bluerint for its DTO? Again, if the 2 should evolve indepedntly they should be duplicated.

    "But, if the application is large and complex enough (like most DDD apps that might even have several autonomous BOUNDED-CONTEXTS), the use of DTOs is highly recommended for its de-coupling capacities regarding data models.  "

    • IoC/Unity: Elimination of abstractions no needed

    I read in a review that this project used the IoC container in many places where its not ideal. I don't know what they mean but that but I think that the IoC should only be used at the infrastructure layer.

    The concept of a "compositi root" is important here, I tinhk, but I didn't have time to explore this.

    I think it would be a very good idea to annoate the Version 2 doucmentation where it differes with Version 1 and explain why the change happenend. This reasoning is very insigtful for people who are trying out this way of arcghiteting their app since they had to make the same decissions and could also go the way version 1 did.

    Kind Regards, Tom

  2. Tom Pester says:

    please ignore the typo's in my post since it's late but wanted to comment already :)

  3. cesardl says:

    Thanks a lot for your constructive feedback. Regarding your comments:

    • DTOs vs. STEs: Both approaches are good and we should go for any of them depending on our application specifc scenario. Like you say, DTOs decouple Domain-MODEL from presentation layer and potential external soncumers, which from an Architectural point of view, is the best. The downsize is that DTOs require more programming. Read this nice article from Danny Simmons: msdn.microsoft.com/…/ee335715.aspx (Take into account that at that time, EF 4.1 CODE-FIRST was not released, but in any case, regarding N-Tier, it is DTOs the subject).
    • IoC. Regarding DI (Dependency Injection) it is the opposite. DI should not start on infrastructure, but on the very begining, for instance, the entry point to your server. Read this post I wrote latetely:

    microsoftnlayerapp.codeplex.com/…/263833

    • The points that V2.0 differs about V1.0 are explained layer by layer in the chapters documentation. But we could create a thread at CODEPLEX for that. Let us finish the work first. 😉

    If you have more feedback, it would be great to have it at our CODEPLEX forum discussions, so more people can comment as well.

    Thanks a lot for your input! We really appreciate any constructive feedback like yours. :-)

    Cesar.

  4. Rodolphe LAÏ says:

    Hello Cesar,

    I would like to know if you still plan to publish the second editionof your excellent book "n-layered ddd architecture with .net" ?

    I downloaded, some months ago, the alpha chapters on codeplex, and reading them helped me a lot. But the codeplex page does not exist anymore. Has the project been cancelled ?

    Rodolphe

  5. Rodolphe LAÏ says:

    Hello Cesar,

    I just seen your posts about why you unpublish from codeplex and where you put the files after that.

    Thanks again to share your excellent work. It really helps me alot in building complex but robust applications.

    Rodolphe

  6. Rodolpho Brock says:

    Hi… I'm still looking for source code as well…