Awkward Coder

I didn't attend QCon earlier this month, but I followed several attendees blogs and co-workers responses to the Eric Evans opening presentation . Alot of people mentioned the fact that Evans wished he'd dealed with 'Bounded Contexts' earlier in the book. I'm now getting this feeling very much on my current assignment - over the last week we've had a great realisation that the application is a chameleon or if I'm feeling less generous a 'wolf in sheep's clothing...' The minute you realise you've multiple different user types using your application you definitely have different 'Bounded Context's'- you could have users who care greatly how 'Orders' are modelled and the behaviour contained within, but you can also have other users who care nothing for how 'Orders' are modelled per say - typically I'm thinking of users who focus on reports etc. This is not to say even if you have a single user you shouldn't giv

I don't mean to demean teachers & teaching but 'IT' has become what teaching had become to any university graduate before 1995 - a fall back opportunity in case you couldn't think of anything more interesting to do with your life. I remember quite a few graduates of the early 1990's who did teacher training just because they couldn't be bother to work out what they wanted to do with their lives, not exactly an encouraging state of affairs for the education system. It was only a fictitious TV show but Teachers hit the mark for me. And now we're reaping the reward of this thinking in the computer industry, notice I don't say IT, I hate the expression 'IT', when ever I hear someone say I work in 'IT' - it tells me ' I couldn't be bother to work out what I wanted so I chased the easy money...' . I'm not saying you have to have a PhD in 'pixel fibrillation and the effects on digital e-commerce' to work in this ind

May be I should be more precise, and say 'No one developer owns the Domain Model...'. We all share the ' code ownership ' and no one coder is responsible for the state of the domain model. Now you're probably thinking I'm going to elaborate on the fact the team I'm currently working with don't take code ownership seriously - they don't - but I'm not going to mention that. I'm talking about when you're a tech lead\coach you don't have 'first dibs' on the structure of the model and how it's implemented. To be honest in a DDD environment we don't have control over the structure of the domain model, the business do! So this week I realised I was living up to my pseudonym, I've been being awkward about other coders adding to the domain model, I've been worrying about what they're going to add or change. Now this is just my hang-up and I realised, how are they going to improve at modelling & design if they a

Okay my first post and I was going to jump right in and try a fill a gap in the blogging worlds knowledge about having a read only collection that supports notifications of modifications to collection members when programming in .Net - what happens when  ReadOnlyCollection<T> meets BindingList<T> ?  The simple answer to that question is ReadOnlyObservableCollection<T>  in version 3.0 or higher - it provides the exactly functionality I require and gets away from the awful 'Binding' prefix name which has to much association with 'Data Binding' in the MS world. But in version 2.0 you don't have a such a luxury :). This is really the sub-text of this post and the problem I'm trying to solve - How can I observe events on a domain entities (including collections) when implementing Domain Driven Design in a winforms environment that utilises an MVC(P) pattern ? If you don't know much about Domain Drive Design check the out website and for a gre