I have no idea what I’ve gotten myself into now, but I’ve agreed to help out the Empirical Evaluation of Software Composition Techniques workshop will be held as part of the next Aspect Oriented Software Development conference. I doubt I will attend ESCOT or AOSD but it will be good to collaborate once more with some very enlightening people that I met at OOPSLA last year.
I guess I’ve got quite a lot of reading coming up and it will be fun to read what is coming out of the research channels and cast my own weird industrial perspective on things 🙂
Tag Archives: AOP
Are you coming to OOPSLA?
In a couple of weeks I will be at the OOPSLA conference in Orlando, USA. I am absolute OOPSLA nOOb but am already excited about it. I’ve heard lots of nice things from the OOPSLA “veterans” at factor10 and now I can’t really wait to get there.
I will be giving a tutorial on using AOP to solve some domain problems, not just removing the infrastructural noise from your domain models. Also, I’ve been invited to be part of a panel on my best-loved-hated subject … modularity. I will also take part in the Cloud Computing Design workshop.
There’s also an amazing line up for the other tutorials and OOPSLA still has a “Pay for 3 and attend 4” promotion going on. Take advantage of it. If you already signed up for 3, then just sign up for the 4th. If you’ve signed up for 2, then pay for the third and register for the 4th too.
So much happening in just a short week. But, it will be lot’s of fun and worth the 24 hour travel time from Cape Town.
My Event Horizon
It’s already halfway through the year, so let’s see what events are is in store for the rest of the year.
June: Next week is SPIN week. Join us after the June 16 public holiday. Same time, same place. Last month we had 40 people attend and we just about ran out of chairs. Lots of new faces. Please come along. The talks are normally good and the conversations are great.
July: Really need to get my act together and get to the next SA Developer‘s talk. Hilton Giesenow tells me it’s a great local event. And On July 27, Lia turns 5! Simply amazing!
August: Hmmm, seems quiet? I think I’m going to submit a tutorial proposal for the ICSE conference happening in Cape Town in May 2010.
September: Looking forward to the Scrum User Group‘s conference in early September. I may be giving a talk on the techie track. I think it’s going to be a great event. Carlo and Peter tell me so. But on September 3, Fiona turns … older 😉
October: My tutorial on using DDD and AOP to create clean, rich domain models has been accepted by OOPSLA. So, October is OOPSLA time for me.
November: I will miss Oredev. The competition to get in was so much tougher. That just means it’s going to be better than last year. If you’re a S.African developer, you should make a plan to get there. It’s a great event that is very high on value for money. But my November highlight is Khaleel turning 9 on the 22nd! Boy, how did that happen so fast?
December: Crazy season again. I really hope it’s a quiet, relaxing one this year.
Øredev Video is Available
The Solving Domain Problems with Aspects talk that I did at Øredev is available. The slides are not clear at all so you may want get the MOV file here and step along.
Øredev 2008
I’ve mentioned it in bits and pieces before but now that the nice folk at Oredev have more or less finalised their program, I can put the down the talks I will be giving in November 2008.
- Architecture Track: Designing for Modularity – one of my pet frustration and, at the same time, fun challenges.
- Agile Track: Managing Diversity in Agile Teams – based on two years of experiences at a rather tough client.
- Java Track: Solving Domain Problems with Aspects – another big challenge for me since aspects are normally used to solve application infrastructure problems.
- Workshop: Bootstrapping your SOA Project – this is a modified version of the workshop I did for IQPC earlier this year.
I certainly did not expect to be doing 4 sessions! It’s going to be a busy conference but also immense fun. I hope that I get the time to attend the other talks and learn from some amazing people. I certainly will be catching up with old friends as well
Subtleties of Ubiquitous Language
There is a thought that has been floating in my mind like an infectious song over the last few weeks and it is Niclas Nilsson’s fault! He posed the question “AOP- Why don’t people get it?” The essence of AOP is the application of old fashioned patterns, mixins and interceptors, using, most commonly, run-time sub-classing techniques. Also, important is that the mixins and interceptors (i.e. the aspects) can be weaved into any object, immaterial of it’s type, place in a class hierarchy, etc. The fact that this happens at run-time in a non-linear fashion (sort of) creates this air of magic around AOP. Not to mention that AOP has some really weird terminology to describe previously well understood concepts.
Andrea Provaglio also participated in the discussion and made the observation that a style class in CSS is, perhaps, an aspect because it alters the appearance of the HTML element to which the CSS style is applied at run-time. Again, I think that if CSS was explained in the language of AOP, it would probably have taken a longer time to gain wide-spread acceptance. What CSS succeeded in doing was to apply a language set consistently, introducing new terms that could be explained using existing, easily understood terms. Even though certain terms (e.g. class) have different meanings when used in the CSS domain, these terms have a foundation in clearly understood concepts.
From a DDD perspective, the use of ubiquitous language is very apparent and thorough in the domain of AOP (i.e point cuts, join points, introductions, advices, etc.). However, I think that the bridge between the language set in the AOP domain and language set of the patterns domain and object orientation domain, from which AOP is derived, is missing. Let me clarify my point with another question: “Would AOP have gained greater acceptance and understanding if it adopted a ubiquitous language set that transitioned already understood concepts (interceptor, mixin, subclassing, etc.) to introduce the newer terms (point cut, join point, advice, etc.)?”
There are three DDD subtleties lurking here:
- Having a ubiquitous language is not enough; the language set must be easily understood and explain new terms using already understood terms. It’s like mathematics. We prove new theorems based on fundamental laws and the already proven theorems. Because we have confidence and faith in the fundamental laws and proven theorems, we gain confidence in the correctness of the new theorem. This results in the acceptance of the new theorem. Similarly, explaining new concepts in a problem domain using already understood and accepted concepts increases overall understanding.
- The ubiquitous language must aim for simplicity and high readability. If complex concepts are explained in a simple language that is highly readable, it is more likely that the concepts stand a better chance of being understood. Overall, our design and solution for the problem domain will stand a greater chance of acceptance from all stakeholders.
- As we explore and gain further understanding of the domain, our language set will change to introduce new terms, bridges between old and new terms, transitions from retired terms to superceded terms, deprecated terms, etc. This occurs during conversation and natural dialog in an attempt to gain further understanding of the domain. But we need to be aware of these changes. What we are actually doing is refactoring our ubiquitous language set. In DDD, the language of the domain is reflected in code. If we refactor our code, we are refactoring our language set. If we refactor our language set, we are refactoring our code.
DDD – Just Entities and Repositories?
Earlier this year Jimmy Nilsson of factor10 presented a great talk entitled “Domain Driven Design – Is it more than just Entities and Repositories?” at PBT Group in Cape Town. I certainly agree with Jimmy: it is more than just entities and repositories. While the entity, value object, repository, factory and other patterns are commonly sprinkled in a rich domain model, the subtleties of DDD such as bounded contexts in strategic design are easily forgotten.
A recent article on infoq.com raised the question Can DDD be adequately implemented with DI and AOP? The arguments are valid in that infrastructure code can be best isolated from a rich domain model using AOP and DI. This is not at all different to Mats Helander’s earlier article on Looking after your domain model.
However, I cannot help the aching feeling that a large part of DDD is being lost with an often blinkered focus on the lifecycle patterns (repositories, aggregates, factories, etc.) and structural patterns (entities, value objects, services, etc.). For example, I am currently focusing a lot of energy with Tania van Niekerk (a work colleague) on the issue of designing for modularity. Modularity is deceptively complex and DDD’s strategic design (bounded contexts, anti-corruption layers, transformations, etc) is certainly helping in us finding a solution.
My take: I agree that AOP and DI do contribute in keeping infrastructure out of a domain model but, more importantly, I agree with Jimmy that there is a lot more to DDD than entities and repositories.
Looking after your domain model
Mats Helander has written an excellent article on how to manage your domain model with some intelligent design trade-offs. It’s a lengthy article that even manages to introduce AOP as well. If you start reading it and wonder where it’s going, just carry on reading…it is written in an evolutionary style. Nice article, Mats! UPDATE: I have written the Java equivalent of the listing in Mats’ article and attached it. The AOP part uses SpringFramework 2.5 and AspectJ.
Trust Everything
Trust has popped up in so many of my conversations recently. It came up at home, at a new school that Lia will be starting next term, in the DDD course that I gave earlier in the month, in Peter Hundermark’s scrum master certification course. And I got a one line email that said this.
The entire world lives on trust. Every aspect in life moves with trust.
The more I think about situations in life that will prove this statement false, the more it seems to hold true. Even in design it holds true. Your most fundamental architectural decisions are based on trust and the implementations of that architecture work because of trust.
It’s true for code too. If you don’t trust the code on which you build or depend, then you might as well write everything yourself, and give up your place on your team.
I was thinking about the AOP with DDD tutorial that I will be giving at OOPSLA this year, and this trust thing came up. Here again, aspects and the classes into which they get woven, need a trust relationship. It may seem like a stretch to make that statement, but I think it holds true again.
So, how do you gain trust? I am not sure, but I think you have give up something first. Maybe you need to show your vulnerability first, then it becomes easier to let someone into your space. Then, perhaps, they will let you in to their space too. When ego walls are erected, then trust finds it hard to grow. By ego, I don’t mean arrogance, I mean awareness of your self that you hide from others for fear. Perhaps, it is only when you show your true interface, that the other will worry less about hidden agendas.
In code, trust lies in interfaces and types, not in implementations. It’s really about trusting the implementation that makes types worthy. When you trust the type and send it a message and it behaves as expected, then you trust it. If you request something of an abstract type and the message was received by an instance of a subclass, then you expect the subclass to behave like the abstract type. You don’t hope that it does behave consistently, you trust that it does!
Trust is tied in with ubuntu too. You can’t be part of a community nor allow yourself to be defined and shaped by the people around you, if you can’t trust them. I think ubuntu coding needs trust as one of it’s values. It’s already a value in XP, and Scrum, and families. It needs to be in teams, and organisations, and communities and nations too.
Reflections on the JCSE Agile and Architecture Talk
It was really good to be part of a very topical subject at the JCSE Architecture Forum last night. While these discussion are so valuable, the things that surface can only be glossed over, largely because of time constraints. I end up feeling a very satisfied and energised but a part of me feels a bit hollow.
So here are some of the things that surfaced at the Forum, and my narrow, unworldly opinion on each (i.e. I’m just trying to fill that hollow feeling).
When we talk about architecture, we need to define what we mean by architecture?
In my talk it was a very simple view of architecture which, thinking back, I should have disclosed very early. I am now applying from Kent Beck who talks about mutually beneficial relationships. So I think of architecture as the mutually beneficial relationship between two or more things. So what is a thing? It could be lines code in a method, methods in a class, classes in namespace, namespaces in code base, binaries in an application server, application servers in a cluster, … see where I am going? Architecture is about creating beneficial relationships, and the 5 things I discussed are based on this view. If you don’t know anything about the things, then you cannot create beneficial relationships. From an agile perspective, the beneficial relationship that you create should only be beneficial based on your knowledge right now. Tomorrow your knowledge changes, so the relationship may not be as beneficial as yesterday. Time to change.
Building infrastructural architecture independently of functional requirements…
I am not convinced of the benefit of this approach. In my limited experience, every business need defines the constraints or needs of the infrastructural architecture. I find it hard to find the point of departure, yet there is a school of thought that suggests that function is orthogonal to the architecture. Perhaps I just don’t understand this. However from an agile perspective, I want to release early and there are many constraints on infrastructure from the business (for example, administrative processes like procurement of hardware). I like to understand what these are early on, reach agreement on what we can release at the earliest and design accordingly. Perhaps the first release is on lightweight infrastructure and that means we “limit” scalability. So, I don’t design for beyond what I know is real.
Model Driven Architecture …
My view is more philosophical and abstract. What is a model? For me, a model is something intangible. It is a way we understand something. But we represent our models in many ways. Through words in written or spoken conversation, in unstructured pictures, in structured notation like UML, even code is a representation of a model.
What do we mean by driven? I view it as a something that takes an input that produces an output. In this case, we take an input, the model, and produce an output, an architecture. So, I take an understanding of problem and use that to derive an architecture. So, that’s nothing new here. However, I don’t like to confuse driving out an architecture from a representation of the model. That’s different. Now we are going beyond thought processes into mechanical processes. Then the challenge is about how to apply the feedback to the representation of the model – and that is what will make you agile. Too much for my small brain.
Plumbing …
Yup, we do too much hand crafted plumbing! It’s something that we have been working on for a long, long time. I think convention over configuration, dependency inversion, meta-programming are all attempts at addressing this problem. Some early success that I have experienced is on taking a polyglot approach. I am not talking about mixing general purpose languages on one runtime only. I am also including domain specific languages. I’ve had some early success where using DSL to describe functional intentions and then generating a large portion of the plumbing. Where I’ve suffered is when I mix concepts from different domains. There is the domain of plumbing and the domain of the business. Whenever I’ve mixed the two, it pains later rather than sooner. Right now, the only way I’ve had some success is with aspect orientation and meta-programming.
@StatelessSessionBean …
Chris Naidoo is right. That thing called J2EE and subsequent versions is just horribly broken. It’s broken encapsulation and a whole lot more. The fact that we now must use an annotation and not implement an interface is immaterial. Both result in the same pain – mixed concepts (see plumbing above). Annotations should be specific to the business such as @RecalculateCostsOnRerouteOfCargo can be used as an interception point for injecting a rule on a class or method.
I would go even further and say that the POJO JavaBean specification is also broken. Why on earth must I have a no-argument constructor and accessors and mutators.
Last thoughts …
I may have missed some of the other discussions but these are the ones that I woke up with this morning. In general, my observation is that we need to be very concrete very early if we want to be agile, even in architecture.
f3yourmind 