Evolving Software

Richard Pawson talks about his experiences implementing a Naked Objects solution for the Irish Government. They went on to deliver 30+ projects on time and on budget!

We’re closed for the month of December, and will be back in January 2012. It’s been a while since the last post, but there are plans to revamp TrueView – a brand new WPF interface and usability improvements are top of the list In the meantime, we wish all of our customers

Someone asked a very important question over at StackOverflow. The answer is also crucially important: “Probably the most important one: not grokking the central, fundamental principle of the Domain Model and its representation in Ubiquitous Language. With the plethora of technology options around, it’s very easy for your head to fill up

Scott Hanselman chats with Richard Pawson about the Naked Objects framework. Find the podcast here. http://www.hanselman.com/blog/HanselminutesPodcast233InsideTheNakedObjectsFrameworkWithRichardPawson.aspx

Although TrueView supports Domain Driven Design, it also embraces the Naked Objects Pattern. This little known architectural pattern is a refreshing (maybe radical?) concept, but complements DDD very well. Here, Dr Richard Pawson (the originator of the pattern) talks about Naked Objects, why it exists, and why a government department uses Naked

TrueView V2 has some significant changes since the last version.  You can download the beta and code sample here. POCO support TrueView now supports POCO classes, that don’t need to be inherited or marked up with attributes. Now you can re-use your POCO assemblies in other applications, and remove the dependency on

The initial release of DomainTypes was heavily influenced by the existing TrueView framework.  After spending much time working with a current client, it’s clear that a more ‘POCO’ approach has significantly more benefits. Based on my findings (and questions over at StackOverflow), here are the major changes: Refined and enhanced most of

A new version of TrueView is in the pipeline for next year.  The features on the whiteboard are: Better support for true DDD concepts Allow code models to be reused without TrueView Configuration without using .NET attributes Open architecture, to let consumers develop custom ‘persistence providers’ More UI interception points, to allow

In the last post, I published the DomainTypes library: a set of .NET interfaces & base classes to provide the building blocks for DDD (source code included). In this post I’ll describe the interfaces and supporting design decisions. IDomainObject Represents any type of object within the Domain model. Currently this is simply

I’ve observed a lot of newcomers to the DDD scene, and typically there’s lots of talk about Entities, Value Objects, Aggregate Roots, Repositories, Factories, IoC, and various technical concerns. But I’m seeing a lot missing from the discussions.  Like “What about the locking implications around an Aggregate?” or “Must Value Objects be