This follows on from my previous posting about Day 1. Unfortunately I was unable to attend the third day, so this is the final installment.
Web as a Platform – Dion Hinchcliffe
This keynote was about the changing landscape of application development and how cloud computing affects it.Â The main point of interest was that even though cloud computing may mean vendor lock-in rearing its ugly head, the cost advantages are going to make it very difficult to ignore. He has much of the same stuff on his blog at ZDNet.
What I’ve learnt since the book – Eric Evans
In this talk Eric Evans discussed what he has learnt about domain driven design since he wrote the book on the subject.
He began byÂ talking about what is essential in DDD.Â Collaboration with domain experts to explore and experiment is important – don’t frighten them away by going through an enormous spec line by line.Â Then evolve the model and language going forward, establish context boundaries and focus on the core domains.
He said that the building blocks (services, entities etc) are less important than the book might suggest.Â But he also said that “Domain Event” is a missing building block.Â It can lead to clearer models by representing the state of entities (e.g. a bank account balance based on the transactions on that account) and can also decouple systems (e.g. a reporting service separate from a transaction service).
Aggregates are consistency boundaries first and foremost and should represent a conceptual whole.Â You need to take care putting aggregate level properties and invariants on the root.Â Sometimes you might need to make a special aggregate object or add a method to the repository.
Something that was in the book that he thought could be left out was Large Scale Structure, which doesn’t come up too often. On the other hand, he suggested a couple of new context patterns:
- Partners – Mutually Dependent and Cooperative
- Big Ball of Mud – Common.Â Know that you can’t do sophisticated modelling within and accept that.
On that second pattern, he said we should accept that not all a large system will be well designed and that precision designs are fragile. It is also possible to spread modelling too thin. Ensure the core domain has a clean context boundary and focus your efforts there. To do the context mapping follow these steps (it isn’t a creative activity):
- What models do we know of? Draw a blob and a name for each.
- Where does each apply?
- Where is information exchanged?
- Which pattern maps the relationship?
Finally he talked about DDD and SOA, which is something he is often asked about.Â He thinks the confusion arises because SOA services carry much more baggage than DDD services, which are just something that can do something for you.Â SOA services are defined within some context and it is quite possible that the service interface may define a context boundary.
OSGi – Neil Bartlett
This was an introductory talk on modularisation using OSGi.Â He started by saying that while jars have dependencies, these are implicit.Â OSGi uses modules, which are just jars plus dependency metadata.Â He had a tongue-in-cheek dig at SOA by pointing out that since we can’t use classes in isolation due to the dependencies we have to call them remotely instead. I was surprised to find out that Spring-OSGi had to be renamed Spring-DM (“Dynamic Modules”) due to pressure from the OSGi Alliance. The takeaway message was that you need to use something like Spring-DM to take care of OSGi for you and don’t code directly to services.
Coaching Self-Organising Teams – Joseph Pelrine
This session used cooking soup as a metaphor for coaching an agile team.Â So you need to keep things cooking nicely without burning.Â I wasn’t quite sure what to take from this.
Value Objects in Domain Driven Design – Dan Bergh Johnsson
This was an entertaining talk on value objects in DDD, which seem to be the poor relation compared to entities.Â Lots of this was just good old fashioned object oriented design, with a domain driven slant. Value Objects differ from Data Transfer Objects since DTOs are a technical construct, whereas VOs are true domain objects.
He showed how pulling Value objects out simplifies the code and helps to avoid bugs, awkwardness and duplication.Â It also helps the business logic concentrate on just that, without getting bogged down in other issues.Â He worked through some examples, with his credit card exchange rate example particularly compelling.Â Having orthogonal classes means that in general m+n tests will be needed where previously m*n would be required.
Good candidates for refactoring include strings or integers with limitations and return values from service methods.Â For example, you could encapsulate a quanitity so that it is never negative.Â Apparently a friend of his working for “a large Swedish corporation” found that anyone entering negative quantities in their online shop would get sent a credit note!
He moved on to discuss how encapsulating multi-object behaviour with composite value objects can improve matters further.Â So you might have DateFrom+DateTo=TimeInterval or Amount+Currency=Money or CurrencyFrom+CurrencyTo+BigDecimal=ExchangeRate. He mentioned Qi4j, which is a framework designed to help do this.