Domain-Driven Design, Thoughts?

ActionScript, Book reviews, Design Patterns, Flex Add comments

Domain-Driven DesignI’m currently reading Eric Evans’ book “Domain-Driven Design: Tackling Complexity in the Heart of Software“. Domain-Driven Design, or DDD, is about seeing the role of the model as the crucial part of a software project, about creating domain logic that is based on the model, about creating an ubiquitous language that is to be used by all team members (even non-technical) and much more.

This is exactly how I have been thinking about application design for quite some time now, especially since I moved from developing web applications that primarily dealt with CRUD operations to Flash platform development. The Flex projects I have been working on for the last years all have pretty complex domain models and they require a whole different approach and discipline in thinking about application architecture.

This might seem very obvious, but in a highly visual environment like Flex/Flash it is very tempting to focus on the User Interface first and hack together a “domain model” that really has a less important role. You end up with a weak model that is hard to expand, debug and Unit Test and in the end it makes you lose a lot of time.

This also gets me to think about the popular architectural Flex frameworks out there. In my opinion they break the principles of DDD by either providing base model classes that your domain model should be based on (Proxies in PureMVC) or by promoting the use of Value Objects as a domain model (Cairngorm).

We use Cairngorm in our projects but we (almost) never work directly on the Value Objects (or should I say Data Transfer Objects). Before an entity or a VO is sent or received, it is pulled through an Assembler that translates it both ways. It is obviously more work to create this mapping mechanism, but my experience is that it really pays off in the end. For instance, if you use remoting and are sending out or receiving domain objects, you have to make all your properties public or you must create getter/setters for them, you can’t properly use constructors since the AMF mapping relies on properties, you have to expose your arrays or collections in order to map them, … This makes the domain model more fragile, something you want to avoid as much as possible.

Another thing that is worth mentioning is the use of Repositories in DDD. Repository is very similar to the ModelLocator known in Cairngorm, but instead of having a singleton model, a Repository is created for a single domain entity. The Repository contains query methods to retrieve objects based on certain criteria. It also promotes not having too much associations between objects because those are hard to maintain and provides association lookup methods.

I’ll try to post an in depth review when I finished the book.

In the meantime, I wonder how many Flex projects are actually dealing with complex domain models and I’m even more interested in what frameworks are being used, if any. If you have any experiences or thoughts to share, please feel free to comment.

Add to Bloglines - Digg This! - - Stumble It! - Twit This! - Technorati links - Share on Facebook - Feedburner

8 Responses to “Domain-Driven Design, Thoughts?”

  1. Dominick Accattato Says:

    Just want to comment that this is my favorite book of all time. I’ve read it a few times and its timeless.

  2. EECOLOR Says:

    Oh, haha. I read your post in my reader and was about to suggest spring and prana (allthough I did not have the chance to work with it myself). But after clicking the post I noticed you are the one writing prana :D

  3. Tony MacDonell Says:

    I am actually really interested in how this book turns out to be. Sounds very interesting, and I may go pick it up.

  4. Peter Bell Says:

    It’s a great book. I ws lucky enough to meet up with Eric Evans at ooPSLA this year in the DDD BoF sessions and it’s a perfect corollary to the code generation work I do as DDD is about eliciting a ubiquitous language, and code gen is about automatically creating applications based on statements in an executable set of ubiquitous languages (in DDD UL’s don’t have to be executable, but I find that for many use cases they can be).

    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.

  5. Christophe Says:

    @Peter Bell: Thanks for your comments.

    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?

  6. Evan Gifford Says:

    Hi Christophe,

    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.

  7. Christophe Says:

    Hi Evan,

    (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?

  8. Hannes Stockner Says:

    Hi Christophe

    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.

Leave a Reply

WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS Log in