What is Domain-Driven Design?

Domain-Driven Design is an approach to software design saying that developers should focus on the domain, by creating a strong model representing this domain and that handles all the domain logic. It was created by Eric Evans and it is presented in the eponymous book, an essential resource to understand all the patterns that characterized Domain-Driven Design (abbreviated as DDD).

These patterns can be separated into three sets:

• The blocks, explaining the basic objects and elements the developer will have to handle when using DDD.
• The advanced elements of DDD, offering a Deeper Insight.
• The concepts for achieving a Strategic Design.

Some of these concepts are ubiquitous: they can be applied to any programming language and / or any software development. However some of them are more specialized, depending on the organization of the project, the teams involved and the different processes. In fact, most of the concepts for achieving Strategic Design (the third set of patterns) are strategies to apply depending of the project context.

This article will not present Domain-Driven Design and how it can help projects become more successful. It will focus on everything specific to Flex development following Domain-Driven Design approach.

Flex and Domain-Driven Design

Flex (and by extend, the Flash platform) is a specialized technology. When you're working on this platform, you usually connect to a server as a client. You also need to be aware of asynchrony, because your application is reachable on the web and the user can access it through different devices (mobile phones, tablets, computers, video game consoles, etc.). You do care of loading time, of the quantity of data to handle and you often ask the question: "should I apply this logic on client-side or server-side?". These are strong constraints forcing developers and architects to adapt. Domain-Driven Design hopefully offers patterns helping your developments in different situations, for example how to work with another system that is sometimes out of control or not part of the same team.

The basic blocks presented in DDD can easily be applied to Flex development: Entities, Value Objects, Services, Factories are concepts and terms already used in many projects. Advanced blocks are also part of every day of a Flex developer, containing patterns like Assertions, Specification, Strategy or the use of Interfaces. Concepts of Strategic Design are really interesting concerning Flex when it comes to a large-scale architecture: there will be many constraints to face and DDD provides different possibilities to achieve efficiency depending on context.

At first sight, DDD seems to apply the same way to Flex as to other technologies. However I think there are some patterns that should be emphasized to Flex developers as they concerns him more directly.

Patterns applied to Flex development

While some basics elements of Domain-Drivne Design like Entities or Services are used the same way as with other technologies, some patterns are particularly interesting to study as they raise and deal with specific constraints in the Flash/Flex context. Let's focus on some of them and remind this list is not exhaustive.

Layered Architecture

In Domain-Driven Design, the Layered Architecture pattern partition the code into four different layers: Presentation, Application, Domain, Infrastructure. The most important part should be the Domain layer, as it is were lies the core of the model, that is to say the core of application. But Flex projects are, by nature, user-interface focused, giving them a strong Presentation layer.

This partition can be considered the same as MVCS (Model View Controller Service), but it is different in the fact that all domain logic should stand in the Domain layer, and not be shared between the Model and Controller part of the MVC pattern. I have worked on projects where some of the domain logic was in the View part, like in a "Code Behind" or a "Presentation Model". Using the Layered Architecture terminology clearly separates domain logic and encapsulates it into a single layer.

It is really interesting to look at how projects / frameworks uses this architecture. Here are two really interesting examples:

• Cairngorm guidelines
• Spring ActionScript Cafe Townsend sample application http://www.herrodius.com/blog/307

Modules

Modules are basic elements of Domain-Driven Design applied to large-scale project. Hopefully, the concept of module is also a primitive in Flex, having native ways to handle them. A module should be treated as a completely independent piece of code, that should have the possibility to be executed alone and have its own test suite.

A Flex module is even more important as he will surely be deployed on the web. Web projects means loading time, and every developer should try to reduce the loading of every application. Flex modules offers the possibility of decoupling your code and at the same time having small pieces of application available separately for the user, that will be loaded "on the fly" only when the user really needs it.

Having this module strategy is then a double advantage: technically (reducing coupling) and for the user, reducing is waiting time.

Ubiquitous Language

Ubiquitous Language is all about communication. Having a shared language between projects participants, but also between different teams. On Flex projects, you will often have many different teams: Flex developers of course, but also server developers (.NET, Java, PHP, etc.), designers, project managers, business analysts, etc. The Flex developer is always in the middle of this workflow: he needs to agree on a contract with the server-side, explains his needs to the designers, listen to the business requirements, etc. That's why he may be the one that needs Ubiquitous Language the most: if he cannot understand and share the key concepts and terms of the domain, he will clearly be confused with one of the actor around him.

Assertions

Assertions is another pattern easily applicable to Flex development. Assertions are tools that will help your code to be stable and so have your domain logic tested. FlexUnit is one of the tools that can be used to ensure that. But other tools can indirectly help assert your code is not broken. Continuous Integration can be achieved with tools like Hudson, offering unit testing reports, FlexPMD reports for code quality, etc. and this done automatically, leaving the developer time to focus on the domain logic instead of testing manually the system.

Limitations

Lately, web technologies evolved so the productivity of web applications increase, offering better tools and less constraints to the developer. As a matter of fact, he can spend more of his time focusing on the domain, instead of some interface problem he encountered before with plain HTML for example. But these technologies still feel the legacy of the web model, some constraints that limits the applications of Domain-Driven Design to Flex development.

Asynchrony

Repositories (a basic DDD pattern) will communicate in an asynchronous way, meaning they must be "aware of this mechanism", having some handlers whenever data is fetched. This is clearly a technical constraint being part of the Domain layer, and though reducing the clarity of it. Using Java, DAO will be used to abstract these operations and hide the way data is fetched, but it is often synchronous operations. What we would like to achieve in Flex is to have this kind of abstraction, hiding implementation detail of this asynchrony to the domain. For example, the Operation API of the Spring ActionScript framework will hide every kind of asynchronous request (remoting, REST, Web service, etc.) behind an interface.

This is one of the constraints for combining Flex and DDD together.

Caching

Sometimes data needed to be cached on client side. It can be context information, some elements related to the current user, etc. All this information should also be available via Repositories, as the purpose of a Repository is to provide access for Aggregates to object instances. Retrieving from a cache or through a distant call is a technical difference that will complicate the implementation of the Repository. Therefore again it is needed to find a convenient way of "hiding" these implementation details out of the domain layer.

Sharing the model with the server

Often in client / server projects, the client will not handle the whole model. For example if the project gather some information from different sources, integrating them on the server side and just passing what to display to the client, it will divide this abstract model in two parts. A Flex module will not handle a complete model but just the information from this model it actually needs to display. Sharing this core data with the server is a key factor for a successful project.

Even if Domain-Driven Design offers Strategic Design patterns to help discussion and communication between different teams holding the domain model, Flex development coupled to a server will raise some difficulties in the fact that you need to chose what information to share to the interface. Also, core logic will need to stay on the server side for performance purpose (think of extracting data from a database and sort it / paginate it using domain data). Working on such an architecture forces the developer to adopt some strategy. Patterns like Shared Kernel or Single Bounded Context are not applicable, limiting the developers to adopt Customer / Supplier Teams or Open Host Service. Off course there is a shared kernel, a core model that you find on both server and client. But because they are coded in different language, they are not synchronized and so need some attention to stay stable.

Having a model focused on what should be displayed and not on the core of the domain may impoverish the model on the client side.

Conclusion

Domain-Driven Design can be applied to Flex projects. The aspect of giving all the effort to the domain model is possible, even if Flex is intrinsically a user interface focused framework. Using some patterns like Layered Architecture or Modules is relevant for Flex development, and clearly give a structure to projects. However, the challenge of applying Domain-Driven Design to Flex resides on the fact that Flex development often involve third-party teams, like a server team and designers. Being this central actor discussing with other people, client developers therefore have the responsibility of using and building the Ubiquitous Language and be proactive to apply patterns like Open Host Service or Customer / Supplier Teams.