Songhay Studio: UX and DDD, my new acronym umbrella…

As of today I am a UX and DDD newbie. My previous 18 years in the IT field represent a dress rehearsal for a conscious performance, under my acronym umbrella of UX and DDD. In simplistic (newbie) terms UX (User eXperience design) covers my “artistic side” and DDD satisfies my scientific needs. I made a possibly self-destructive but financially necessary decision to postpone my UX interests until I could stabilize my interests in hard-core tech. The analogy I would often use is the one about the painter who becomes a carpenter just so she can build her own frames (which are often too expensive to buy)—or the one about the poet who holds back the poems until he can make his own paper. For me, DDD (Domain Driven Design) is the culminating ‘conceptual container’ big enough for my technical needs—strong enough to support the “art” that I insist still simmers within me.

My house that DDD built came from one stone of an issue: immutability. When I first started “consulting” for PIMCO 12 months ago, I encountered a WPF front end built over a Java backend, served with IBM WebSphere MQ. To my newbie horror, I discovered that immutable objects were being sent into an MVVM-based system that is designed for two-way data-binding with mutable objects. I immediately rebelled under the principle that Microsoft did not design a MVVM solution to handle this scenario—and, had my savings been large enough, I would have walked out of the PIMCO offices never to deal with this issue again. That would have been a tragic mistake.

PIMCO has some of the finest WPF developers in Southern California and when I turned my problem into a team effort (instead of being “a guy in a room”—a gloomy character from Jim McCarthy’s Dynamics of Software Development), these issues were resolved. (Also, by sharing my problem with others, I found out that my problem was one of the hardest on the shop floor.) Before I go on, it may help to mention that all that is written here are my opinions and assertions. I am not repeating what was taught to me or expressing the views of any third party.

First thing: MVVM as we now know it, encourages the use of what DDD folk call “anemic domain models.” What we had to build at PIMCO was a gigantic workaround for this anti-pattern. I do not see the need to go into the details of this workaround (in part because the developer that built key features would not approve) because I predict that Microsoft (perhaps after Xamarin) will adopt and promote a successor to MVVM that is DDD-friendly. Also, it is very important to note that Julie Lerman is well on the way with reconciling DDD with the Entity Framework—so her work should be vital in this context as well. Anyway, here are some highlights of the workaround:

• Build mutable, “presentation,” View Models that wrap the immutable server objects. The immutable DTOs are injected into the “presentation” View Model constructors. These presentation View Models can intercept “anemic” RaisePropertyChanged() events and interpret them into Domain-specific server requests (I designed and built this piece—not as hard as the other stuff)
• Build a parent View Model that observes the “presentation” View Models and construct domain-specific requests from subsets of these “presentation” VMs (I also designed this bit).
• Build a presentation collection based on ObservableCollection<T> to store these View Models and compare them with new DTOs (incoming as responses to my Domain-specific requests) injected via a “factory lambda” passed into the constructor of this collection.

Based on Google/Bing searches over the last 12 months, I assume that I am one of the few people in the world who took the time to write about this problem publically (electronically). I look forward to being awaken from my delusions of grandeur when someone out there is kind enough to come forward and talk about their solution to this problem. Does Reactive UI have something for MVVM anemia out of the box?

Related Links

https://github.com/BryanWilhite/