Developers often concentrate all one’s effort on the technical infrastructure, learn different libraries and frameworks believing that the sole use of them makes the software better.

In my opinion a good approach for new projects would be to find an ubiquitous language between domain experts, software architects and developers to make them understand the business domain and following, to make them elaborate a rich domain model which reflects what they are talking about. So the model becomes the basic of the language used by all team members. It becomes the heart of the application as it solves domain specific problems.

This approach does not exclude the use of any frameworks. A framework such as your IoC Container can support the Domain Driven Design philosophy, but the main focus should not lie on it.

(I didn’t even know there was a Cairngormdocs group. I joined and thanks for mentioning.)

The projects I’m working on have almost all of the business logic on the Flex client. The server is primarily used for persistence and does not contain much business logic. This is because we want to be able to swap server implementations or even take the client offline in an AIR app.

That being said, it was not interesting for us to work directly on the DTO’s and have our business logic in commands. Actually, I think commands should not carry domain logic at all, but I’d much rather have a solid domain model with objects that contain the business logic (can we say DDD here?). It feels much more natural to invoke a business method on an object than to have to dispatch an event to carry out that business logic.

The commands we have are now only used to invoke delegates which invoke services and do the translation of the model objects and the DTO’s.

Does that make sense?

This subject recently came up on the Cairngormdocs group. The question was about the business logic for calculating a sum of the data on a ValueObject.

There seems to be a correlation of a “Repository” to a “Model Object” in Cairngorm. Although the lines may be blurred when one binds directly to a property.

As for the DTO transformation layer, is it needed if the service was created specifically to support the client? If the DTOs have semantic meaning on the client, why translate them?

In general I agree with translating them. What if those services go on to become more general and support multiple clients?

But specifically for the kinds of applications with involve a service with the sole purpose of supporting a specific client, I generally leave the DTOs intact.

The last benefit of this method is that the VOs are canidates for code generation. If the schema changes on the server, a quick rebuild of the VOs and remapping a few properties on the client is all that is needed.

I’m curious to know how implementations will differ between asynchronous Flex clients and AIR clients that use an embedded database with synchronous communication. Or maybe even a combination of both…

In general, I find it hard(er) to develop an asynchronous system. You start out with a clean domain model and have it perfectly set up with tests but then the server communication needs to be implemented and it becomes quite of a blur. I’m especially referring to the commands/delegates/modellocator chain in Cairngorm. Do you have any experience or best practices to share?

The idea of repositories is similar to the Service class singletons you’ll often find – either one per business object or one per major domain concept in back end languages like ColdFusion or Java.

I find that when I spec a project I start with screens and actions, but I describe all of the screens and actions in terms of the domain objects they need to display, filter, edit, report on, etc. In a Flex project you may well find that the “smart” stuff is being done behind the scenes behind your remote API written in the back end language of your choice. The problem with creating rich business objects within Flex is that you’re going to have to replicate that logic elsewhere if you want to support multiple front ends for a given back end object model, so we’ll usually handle all of the rich object functionality on the back end and then provide an API for accessing and modifying the domain objects so the Flex system can focus much more on the user interaction part of the process.

Definitely lots to be learnt from DDD though.