Domain Driven Design

I’ve been talking to a few friends for a while about adding object modelling into XP stories and having an overall view of the project held as an interaction diagram (often called a storyboard) and backed up by an object model that describes the problem domain.

Anyway, when I mentioned this to Richard Watt and Martin Fowler of Thoughtworks they suggested that I take a look at a book due out soon called Domain Driven Design, Tackling Complexity in The Heart of Software by Eric Evans which talks about a very similar concept.

Evans talks about the use of a single Ubiquitous Language that is used by the whole team – customer and all. That is, you educate your customer in Object Modelling, to some extent.

http://domaindrivendesign.org/book/

Well worth a read.

Role of Architect

What a wonderfully eclectic group we are! It is clear that we all bring many different levels of ability and many different experiences to the mix here. While this is the lifeblood of any organisation it can have a damaging side-effect. If people are not self-aware and self-evaluating there is a real risk that the same things that have been done before keep getting done again and again, regardless of their suitability.

Continue reading