Christophe Herreman

I have been thinking about some of the concepts and patterns described in the Domain-Driven Design book and how they could be implemented in a Flex or AIR environment.

One thing that interests me in particular is the use of a Repository as a container for Domain Objects. In short, a Repository is responsible for fetching, persisting and manipulating objects. Its intent is to shield the client from the implementation details of the data storage or the remote services that are used to get and manipulate objects.

However, there seems to be a fundamental problem in creating an ActionScript implementation. Since remote services are handled asynchronously, it is impossible to create a Repository as it is originally described by Eric Evans.

Here’s a snippet of a post (by myself) on the DDD list:

Would it be correct to assume that repositories don’t make much sense if you are dealing with async remote calls? Or should I say that async data fetching is a problem currently not addressed by DDD? Quoting Eric Evans in the DDD book (p. 157): “The client of a REPOSITORY should be given the illusion that the objects are in memory.”. That being said, it is no problem to call a method on a repository and have it return the objects immediately if the objects are in memory. But, if the objects are sent back asynchronously, the whole point of encapsulating that behavior is gone since the client needs to “listen” for a response on the repository. So it knows about the implementation details of the repository.

As a reply, someone offered to try to make the call synchronous by waiting for a result. Although I think that might work, for instance by entering a loop until the result is received, I’m not completely sure as I haven’t tried this. Here’s my reply:

The problem I see is that the UI will be locked/frozen until the response is received because the code runs in a single thread within the Flash player. That means it won’t be possible to create a (animated) loading screen to give the user some visual feedback. This would probably not be a problem with remote calls that return a small amount of data and a fast remote connection, but it certainly will be a (usability) problem if the connection is slow or if we are loading large chunks of data.

Conclusion

So my conclusion at this moment is that implementing Repository in Flex doesn’t make much sense since the client still needs to know about some of the technical details of the implementation. Locking the UI would most certainly lead to usability problems (if it would even be possible). On the other hand, a Repository could be perfectly implemented as intended in an AIR application that uses an embedded SQLite database and synchronous calls, but the UI would also be locked.

Thoughts?

A post on the Domain-Driven Design mailing list got me to reflect on a recent project we did in the domain of accounting. This was a completely new and unknown domain for us as a team and it sure took us a while to grasp the different domain concepts. After some meetings with the (Dutch) clients and as soon as we had enough understanding of the domain, we started developing.

(On a side note: I couldn’t help but notice that our client was pretty inpatient whilst teaching us about accounting.)

As a company-department standard, we program all code in English since it feels the most natural given the fact that most (if not all) API’s we use are also written in English. However, we quickly faced the following problem: What are the English translations of the different domain concepts we just learned as part of this accounting application? As a result, I spent a fair amount Googling around to find dictionaries with accounting terms and finally wrote down a translation scheme for the domain objects.

Although I’m pretty sure we got the correct translations of the domain objects, it felt awkward at times to work with the API we were creating. In fact, it made developing quite a bit harder because we had to constantly translate terms when we were talking amongst developers and when we were talking with the domain experts/the client at iteration meetings.

On the other hand, mixing Dutch and English code is also pretty awkward and could make the code hard(er) to read. So I’m still kind of undecided about what option to choose. I guess it depends on how transparent the translations of the domain objects are and how easily they are interchangeable.

Does anyone have any experience with this? How are or would you be handling this situation? Do you prefer sticking to English with the added complexity of dealing with domain object translations or do you develop in the language of the domain experts?

Damn you tower.