This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Thoughts about a conversation with Ralf Westphal at the Prio Conference
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
Well, I���m on my way back from Germany now after two intellectually-filled days at the Prio Conference in Baden-Baden. I finally got to meet Ralf Westphal with whom I���ve been emailing back and forth for over a year now. I saw Christian Weyer and Dominick Baier again after meeting them at TechEd Developers Barcelona. You can imagine that the conversations centered around large-scale distributed systems design.
On my first night there, after a delicious speaker dinner and several drinks Ralf and I waned technical. After spinning through some pub/sub, Ralf challenged me that he could implement all of the concepts I used between services and within them, client-side included, with holons (read Ralf���s blog for some background on this).
After debating back and forth a bit, I realized that almost all of the components in the solutions I design have a Command / Notify style interface. My persistent domain objects followed the Domain-Driven Design practices espoused in Eric Evans book (by the same name), and ended up exposing just such an interface.
High-level communications between services followed the same principles. Services received command messages and notified external services about state changes by publishing notification messages.
Even the repository in which objects were stored on the client side exposed the same style of interface. The methods ���Save��� and ���Delete��� caused the repository to raise a ���RepositoryChanged��� event. The only part of the repository that didn���t follow this pattern was requesting an entity based on its Id.
While it may not be the unified theory of everything, I was beginning to believe that this could be used as a general design principle ��� effective for teaching new architects how to get started. By combining this with my first principle of design (formerly known as Udi���s first rule of design) ��� interaction between classes must be through an interface, with each class and interface in a separate package ��� I think that we have a firm, yet simple foundation for architects to build on.
Just as an aside, I���ve changed the word ���rule��� to ���principle��� because there is a general case where it should not be used. When you have a class that fulfills a role like Supervising Controller, or Message Handler and it needs to interact with classes fulfilling the role of Domain Object ��� either server-side or client-side, the ���rule��� should not be used as it will cause unnecessary complexity with no benefit.
Finally, Ralf left me with an interesting idea to mull over. Given that both in-process and inter-process interactions follow similar patterns when loosely-coupled, could we create a design which could be distributed in multiple ways differing only in the system-level quality attributes achieved. My current thinking is that were you to do such a design when thinking about distribution scenarios, you could be able to co-locate all elements on a single machine, or even a single process, and have it work. I���m not sure that if you did such a design when thinking about single-process deployment the result could scale out as well as the first design. I���ve done the former and been successful, but haven���t tried the latter yet.
Anyway, at that point it was already late and I was tired after spending most of the day changing planes, and trains, and even cabs, so I called it a night ��� dreaming about component, service, and holon societies.
Previous Topic
