nk4um

If you fall for one of these at best you will lose thousands of dollars; at worst you will lose your life. These usually start with an email from a bank official or the relative of a recently deceased African president or a government minister informing you that they have <a href="http://www.asianluxuryescort.com">new york asian escort</a> access to millions of dollars but need your help to get the money out of the country. The end result is that when the deal is threatened you will <a href="http://www.asianluxuryescort.com">new york asian escorts</a> be asked for money to secure the release of the funds. Do not <a href="http://www.asianluxuryescort.com">new york escort</a> under any circumstances reply to these letters, people have been murdered while following up with these scams.PhishingPhishing scams can be very elaborate, scammers send out emails to millions of internet addresses purporting to be from a financial institution, and requiring you to log in and <a href="http://www.asianluxuryescort.com">new york escorts</a> confirm your details. The email looks authentic and contains a link that you need to click.

I''ve been at the Skillsmatter DDD Exchange.  Its clear that the DDD thought leaders share a common view of the world as we ROCers.  I thought I''d capture some quick notes on where we overlap (and hint at what lies beyond DDD in the world of ROC).

Domain Driven Design has a core set of concepts:

Domain:
   The subject area of interest (the business domain).
Model:
   A system that represents a solution space for the domain problem.
Context:
   The language and vocabulary in which the solution is expressed

These core concepts are applied using software building blocks...

   entities
   value objects
   services
   domain events
   aggregates
   modules

Essentially DDD solutions are built and implemented using classical object oriented techniques.

Ultimately the goal of DDD is to break the tyranny of dogmatic brittle architecture by pragmatically allowing the real world business domain to inform the architectural structure of the solution.  A classic example, reiterated frequently, is that business logic cannot be applied at a central physical layer - it necessarily spans data, middle and client layers.

Its very clear that the core set of concepts (domain, model, context) are common with ROC.  Indeed ROC takes the concept of context and brings it to life as a living boundary condition within which any system executes.

DDD recognizes that there is no "one-size-fits-all" model.  Indeed it encourages the discovery and pragmatic adoption of models.  This is very much in line with ROC in which it is a fundamental axiom that any information has any number of identifiers and representations (value objects).

DDD encourages immutable DTO''s.  ROC requires that representational state be immutable.

DDD encourages service based models.  ROC models all information transformations as services, indeed any resource request is resolved to an implementing service.

DDD says that layers and tiers are not the same thing and that physically partitioning must not restrict the logical model of the solution.  ROC and the address spaces take this to the limit and say that architecture is not even restricited to 2 dimensional structures but can be layered with vertical resource channels.  ROC spaces make arbitrary and appropriate architectural structures to be deployed - most importantly they can exist concurrently within one solution and one space may be used in any number of appropriate locations.  (In the limit and if required, ROC allows this aspect of DDD to be taken to the limit, with dnymically composed archicture based upon application state).

DDD suggests that "aggregates" are a flexible way to cope with the natural multi-dimensionality of real world information values.  ROC recognizes that the part-whole duality is intrinsic to the nature of information and as a direct consequence that systems naturally evolve through composition and the accummulation of composite state.  Indeed often these composite resources include links to other resource which become relevant and useful in the context of the recipient of the request (cf HTML, links, img and csss in the context of a browser render engine).

DDD naturally suggests that separating read and write sides of the architecture offers best architectural value.  ROC recongnizes that read-side state transfer is naturally partitioned and seperate from write state transfer.

So are DDD and ROC the same thing? Not quite.  While the world view is very similar, and the modelling and mental process of considering architecture are both motivated to overcome the innate brittleness of OO architectural orthodoxy.  DDD remains within the OO paradigm, its building blocks and patterns and the approach to adopting DDD are innately OO-centric.

ROC says, there is world that lies above OO, a world in which the building blocks are:

   identifiers
   spaces
   requests
   endpoints
   represntations

These building blocks give us first order control over the architectural strucutre of our solution.  We can model the domain, create spaces that embody the contextual information boundaries and dynamically compose solutions at a larger scale than DDD-OO.  (Of course within endpoints etc we also descend to the level of OO - and existing OO DTO''s etc are not excluded).

Furthermore ROC introduces whole new systemmic qualities, state normalization via systemmic memoization (caching everything).  Threadless scaling and multi-core concurrency.

Finally, DDD remains a localized internal approach to architecture.  ROC (with the NK protocol (NKP)) allows the abstraction and ROC building blocks to seamlessly span servers - to offer a true DDD/ROC cloud architecture.

In ROC we talk about the 3C''s.  Construct, Compose and Constrain.  I believe DDD has the same 3C''s - however by implementing with OO they are in danger of always having the "C of Constraint" grabbing hold too soon.  ROC lets you play with the archicture using consturction and composition and offers the ability to explore and solve problems without the tyranny of pre-constraint.

If this makes any sense then please take a look at NetKernel  http://www.1060research.com/netkernel/ - its a full ROC platform.  Take care though, it might just blow your mind.

PJR @ the Skillsmatter DDD Exchange June, 2010