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 used as a marker, signalling to developers that the implementation has DDD semantics.

IEntity

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).

IValueObject

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).

IList<T>

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.

IEvent

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.

IAggregateRoot

Most people understand Aggregate Roots as a cluster of closely associated entities.  However, there are 2 additional concerns that an Aggregate Root has:

1. It knows how to validate the entire aggregate
2. It is used to lock it’s contents in a multi-user environment

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).

IFactory<T>

Used to create Domain Objects/Entities/Aggregate Roots that are complex to build.  Only use factories when the code within your constructors becomes unweildy.

IRepository<T>

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.

IService

Currently this is simply used as a marker.  Only consider using Services if :

1. Try as you might, you can’t decide on which Domain Object to place your logic
2. The logic requires the use of several unassociated Domain Objects
3. You’re communicating with another module/tier/component

The remaining interfaces aren’t DDD specific, but are to aid real-world implementations.  I’ll discuss those in the near future.

Download the source code

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:

• IDomainObject
• IEntity
• IAggregateRoot
• IValueObject
• IList<T>
• IFactory<T>
• IRepository<T>
• IService<T>
• ISpecification<T>
• IQuerySpecification<TRequestor, TResult>

Additional interfaces for orthogonal concerns are:

• IPersistable
• IPersistableList<T>
• IAudit
• IAggregateLock
• IAssertion
• IDependencyAware
• IDependencyLocator
• ITrackable

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.

Download the C# project

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.

http://www.scribd.com/doc/21997741/DZone-Refcard-76-Domain-Driven-Design

You cannot upgrade this prerelease version of Windows 7. Go online to see how to install Windows 7 and keep your files and settings

A quick Google found these instructions.   Should save you the hassle of rebuilding your PC

One of the topics that caught my attention was Exploration and Experimentation (3m 25s into the video).  Evans suggests that teams should be exploring & experimenting even after a useful domain model is created.  His quote:

What are the odds that [the first good model] is the best you could have done?

So why aren’t teams doing this already?  Typically, it’s because of fear and cost of change. Traditionally, software has never been easy to change (read expensive).  And for all of the new technology being spewed out, not all of it is designed to make change easy.

This is the void that TrueView attempts to address.  It’s not about UI design, or database design, or Web Service contracts.  It’s about creating interactive domain models that Domain Experts and Software Experts can explore, discuss, and help refine the ubiquitous language.

If you haven’t tried it already, you can download it here. I hope you find it useful.

In summary, focus on the core domain – the part of the software that brings competitive advantage to the business – and use an anti-corruption layer to interface with the old system.

I’ve observed that a lot of DDD newbies get hung up on Value Objects, persistence, how to normalise the database, and other implementation concerns.

Value Objects stem from the actual domain problem, not from  persistence.  Read Dylan’s post to understand why.

Michael Smethurst (Information Architect at the BBC) describes how DDD is used to make websites.

“What’s so bad about that?” I hear you cry.  Well, here’s the problem:

UI prototyping is great for defining how a person is going to solve a business problem.  It’s not great at defining what the problem actually is (i.e. the business domain).

I’ve seen this happen many, many times:

1. Developer sketches UI, to start discussions with the Domain Expert/Business Analyst
2. Business Analyst adds/removes/repositions some widgets
3. ‘Hand waving’ and ‘pointing at imaginary boxes’ becomes the communication technique of choice
4. Developer agrees to ‘quickly code up’ an interactive prototype
5. End user wants a different shade of blue

Although the Developer has good intentions of leveraging DDD, the urge to see working apps overrides everything else – leaving the Developer with a vague understanding of the business domain.

As the Developer does learn more about the domain, he usually finds that the original UI design is inadequate. And changing a UI is expensive (it’s a pity that most businesses don’t understand why).

This is where TrueView shines.  It automatically creates interactive UIs, but only based on domain definitions and relationships. Which means:

• The Business Analyst must describe the business domain.
• The Developer must start understanding the domain
• Both must define and share the Ubiquitous Language.

TrueView doesn’t give you a totally customisable UI, but you do get an interactive prototype that models the business.  Once you understand the domain model, you’re in a perfect position to design a slick UI.