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!
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 and colleagues a very Merry Christmas and a prosperous New Year!
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 with ORMs, MVC frameworks, AJAX, SQL vs NoSql, … So much so there’s little space left for the actual problem you’re trying to solve.
And that’s DDD’s key message: don’t. Instead, explicitly focus on the problem space first and foremost. Build a domain model shorn of architectural clutter that captures, exposes and communicates the domain.”
Of course, I had to give this answer my vote too…
Scott Hanselman chats with Richard Pawson about the Naked Objects framework.
Find the podcast here.
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 Objects to build their key systems.
Compelling viewing for anyone who wants to take Agile and DDD to the next stage.
TrueView V2 has some significant changes since the last version. You can download the beta and code sample here.
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 TrueView framework.
To make your POCO classes viewable in the UI, add the following property:
public Guid ID { get; set; }
To make your classes persistable, add a Version property:
public long Version { get; set; }
Check out the included sample code to learn about the new features.
P.S. There’s a new DomainTypes library available as well.
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:
I’ve also added more examples to clarify how you might use the interfaces.
You can download the code here. All comments are welcome.
P.S. Note that this library is NOT compatible with the current TrueView framework. Watch this space for the new version!
A new version of TrueView is in the pipeline for next year. The features on the whiteboard are:
And we’re considering making TrueView FREE for non-commercial use.
We’re going to need beta-testers for the new version, so if you’re interested please email us.
In the meantime, have a very Happy Christmas!
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.
Represents any type of object within the Domain model. Currently this is simply used as a marker, signalling to developers that the implementation has DDD semantics.
Represents a unique Entity within the system. The ID property is used to identify the instance during it’s lifetime. Using a GUID allows identity to be established without having to talk to a persistence store (i.e. database).
Represents a non-unique object within the system. Note that it’s an object, and not a struct. Structs may seem like a better semantic fit with DDD, but too many instances can cause memory problems (structs – like value types – are created on the stack).
Represents a list of Domain Objects. It’s crucial that the implementing class raises events before items are added or removed from the list. This allows consumer code to execute any domain rules, and cancel the action if necessary.
This is one that Eric Evans mentioned earlier this year. It is used to record & identify domain events, and must be immutable. For example, a child’s birth should be captured, be identifiable, but never modified.
Most people understand Aggregate Roots as a cluster of closely associated entities. However, there are 2 additional concerns that an Aggregate Root has:
The IsConsistent() method is a placeholder for all rules/invariants that apply to the aggregate. The locking concerns are handled by IRepository<T> (see below).
Used to create Domain Objects/Entities/Aggregate Roots that are complex to build. Only use factories when the code within your constructors becomes unweildy.
Used as a facade to a persistence store. Strictly speaking, repositories should only deal with Aggregate Roots – to access other entities you would navigate through the Aggregate.
In addition to the typical Load()/Save()/Delete() methods, I’ve also included Lock() and Unlock() methods. This is a crucial function in a multi-user system, and should be considered when designing your Aggregates.
Currently this is simply used as a marker. Only consider using Services if :
The remaining interfaces aren’t DDD specific, but are to aid real-world implementations. I’ll discuss those in the near future.
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 immutable“, or even “How do entities retrieve data if they can’t access a repository?“.
To that end, I’ve created a set of interfaces and base classes that represent the building blocks of DDD. The idea is to get developers thinking about key concepts early in the design process, and let Intellisense provide some guidance.
You can download the source code here. It has a Ms-Pl licence, so you can modify and use the code as you wish.
The DDD related interfaces are:
Additional interfaces for orthogonal concerns are:
This is still a work-in-progress, so feedback would be greatly appreciated. In the next couple of posts, I’ll describe the interfaces and classes.
P.S. The next version of TrueView will be based on these interfaces. So if you code a domain model using the compiled library, TrueView will auto-generate a completely interactive UI (with the appropriate semantics) directly from your model.