Continuing our series, I’d like to present an architecture that I’ve been working on and can be used in Silverlight LOB apps that are developed using DDD (Domain Driven Development) and have N-layers.

The following picture describes how an application can be layered into multiple Modules, all hosted within regions of a Shell. These modules can communicate with each other through well defined messages and contracts defined in the module Infrastructure layer. Furthermore, they retrieve and manipulate data objects through WCF Services that are suited for DDD (called WCF RIA Services). These data objects are often called entities and can represent your Domain Model and are persisted in a data store using Data Access Objects that abstract both the data store and the data access technology you’re using. WCF RIA Services provides ways for you to manipulate your entities in the client similarly as you would do in the server when it comes to querying, changing data and submitting changes.

Such application often relies on server-side infrastructure for authentication and authorization, logging and error management. At the client-side they rely on frameworks that help reduce, harmonize and reuse code in module development both at the presentation logic and at the presentation views. Some layers may have components that depend on components from other layers. In such cases, we reduce these dependencies with IoC containers or similar frameworks like MEF.

Developing in an N-layered architecture can be troublesome when you want to reuse code that has to be specified both at server-side and at client-side when it comes to validation or other business logic. WCF RIA Services relies on metadata that describes entities how entities are defined, validated and how they behave with each other. Although this technique is very effective, there are related problems that aren’t noticed until you actually hit them and I’ll try to identify and address some of them.

Notice the mapping layer between the Data entities and the Domain entities. This layer is “optional” and can be useful when you don’t want to expose your data entities as your domain model. This helps achieve persistence ignorance and also allows you to create simple and lightweight classes to transport data. For simplicity, I’m not going to use this layer in the upcoming posts, so my data entities will be my domain entities.

In the following posts I’ll be building an app that respects these layers and will evolve over time. I’ll also build a simple framework aimed for MVVM development to show how effective this pattern can be.