You really piqued my interest with this Domain Inheritance concept but I'm having trouble envisioning how the workshop would be - could you perhaps open up the implementation a bit, for a techie like myself who is dying to understand whether it's going to be drawing lines and boxes, learning a new DSL-ish programming language, or stretching a familiar language to new shapes and forms on top of a framework of some kind?

This sounds like an interesting session. Do you have specific needs from the organization for your workshop?

Do you need extension cables? Do you need participants to participate in the Dojo also? Is it only one laptop with projector? Do you need a particular set-up in the class room?

Do you have some data points to support your first statement "Agile Methods have matured up to a level that the next giant leap in scaling agility will not be achieved through further methodological refinement, but will require a technological breakthrough."?

I would expect that to be described in the introduction of the session.

Hi Lasse,

It has everything to do with Separation of Concerns (SoC).

There are a numerous ways to separate concerns.

Even OO is a way of separating  concerns into classifiers, methods and attributes.
Using design patterns is a way of separating concerns (e.g. factory method is a separation of construction, strategy is a separation of behavior ... )
Even the dreaded 3-tier architecture is a classical case of separation of concerns.

But separating concerns almost always results in some 'constructs'  to become dominant, some even speak of the tyranny of the dominant construct. (e.g. in OO this is the class, in functional languages this is obviously the function, in logical programming these are the facts and rules, ...)

Most of these SoC methods focus on the lowest level (e.g. the object, object interaction (design pattern,  ... ), but in larger systems we also want to separate concerns.

The most notable attempts here are SOA (functional SoC), Component Based Development (functional and OO SoC), Aspect Orientation (agnostic SoC).

Today most of the research is in Aspect Orientation (AO).

I didn't want to include the AO in this session, because I'm afraid it would become too academic, but I started to realize that contrasting Domain Inheritance with AO can be beneficial in understanding Domain Inheritance.

The drawback will be that the level of difficulty for the session will rise (considerably).

In AO there are two big families:

1) The asymmetric family

This the AOP we all know from AspectJ and other frameworks.
It is asymmetric because there is one primary domain, where you implement your business objects and there are aspect domains. The aspects domains get composed with the primary domain in a composed domain.

The main application is for cross-cutting concerns. (e.g. add logging or security)

2) The symmetric family

This is known (primarily) as Subject Oriented Programming.   Here you compose domains that are peers. There isn't a primary domain, they're all primary. Most notable framework here is (the now defunct) HyperJ.

Domain Inheritance:

Domain inheritance is actually a generalization of the OO model to domains. Domains can inherit from other domains.

In Domain Inheritance we are also composing domains, but this composition exhibits very different characteristics then the (other) Aspect Oriented 'families'.

a) it is hierarchical: sub-super relations ( as opposed to symmetric/asymmetric )

b) It is not for cross cutting concerns (as opposed to AOP)

c) composition is automatic for state and (semi-)manual for behavior

   (this is a big difference with current AO methods, especially with  Subject Oriented Programming where the manual composition rules are overwhelming)

d) Domain Inheritance's natural habitat is the analysis level

e) It has fewer composition rules and the rules are fixed (only addition for state, no modification/merging/removing)

f) As in OO, there is a clear dependency form sub-domain to super-domain (vertical).
   But there is also a dependency from extensible domain to extension domain  (horizontal).
   This seems quite harsh, but these rules make composition of the domains and understanding the composed domain very easy.

g) It focuses on domain composition, not on element composition.
   (elements here mean relation endpoints (attributes) and methods)

h) Conflict resolution is the exception ( in symmetric AO conflict resolution is the rule)

This is a lot to chew on, but I hope it tastes good

Hi Vasco,

I really like group programming, so one computer and a beamer should suffice

But maybe we can add some cases that participants can complete on their own laptops.

Hi Marko,

Yes, this is a firm conviction I have.

Methodology and Technology are very connected (even interwoven).

"Agile Methods were born out of need, a need created by Object Oriented Programming".

I know this is a very bold statement! But look at it empirically, (almost) all of the 'Agile Gurus' stem from  an OO background (Beck, Cockburn, Fowler, Schwaber, Martin, Thomas, Coad, Booch, ... and the list goes on and on).

Is this a coincidence ?

I think not, there was no need to switch to an Agile Method in the 'classical structured 2-tier programming' world. Anyone wanting to change the database in the midst of a project would be put in a straight jacket and sent to an asylum

Now enter OO with its encapsulation!

Changing relations and methods that are sufficiently encapsulated becomes easy. Refactoring is born! So, OO begged for Agility and a lot of people doing OO were 'forced' to an Agile method, it was not a choice

Technology has a huge impact on methodology!

To elaborate on the statement you mentioned: Yes, I truly believe that with the current state of 'technological' affairs current Agile Methods have probably reached their limits.

Every 'profit' gained from Methodological refinement will only be marginal ...

Maybe in the future there will be a new technical revolution that will require less Agility in its methods, maybe there will be a new technical revolution the will require even more Agility in its method? Who knows?