Posts Tagged ‘domain driven design’

Free .NET type library for Domain Driven Design + source code

Thursday, November 19th, 2009

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:

  • 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

Interfaces

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.

Eric Evans: “What I’ve learned about DDD since the book”

Tuesday, June 30th, 2009

Eric Evans talks about the most essential parts of his book, having practiced it over the last 5 years.

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.

Eric Evans: Why do efforts to replace legacy systems fail?

Friday, June 19th, 2009

Gojko Adzic has an interesting piece by Eric Evans about replacing legacy systems.

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.

Tips for Domain Driven Design and TrueView

Tuesday, June 2nd, 2009

Here are some tips for DDD newbies.  It’s easy to fall back to doing ‘what you know best’, so use these tips to stay focused. Hopefully your design skills will get better (and faster) as a result. :)

  1. Don’t start with the User Interface
    Instead of asking “How will the user solve this problem?“, ask “What is the problem?
  2. Design Domain Models, not database schemas
    Most business users don’t understand database schemas – so don’t make them
  3. Design your Domain Model incrementally
    Defining too much detail early on is the fastest way to get side-tracked
  4. Get constant feedback from your Domain Experts
    Take advantage of TrueView’s auto-generated prototypes to get instant feedback
  5. Separate business concerns from technical concerns
    Writing technical infrastructure code can be counter-productive during the modelling phase
  6. Unit testing wisely
    Focus on testing non-trivial behaviour and complex business logic, possibly using BDD
  7. Think agile, be agile
    Your clients don’t have time to wait, so don’t make them

You can read the detailed version here.

A quick chat with Eric Evans

Thursday, March 26th, 2009

Eric Evans chatted with Alex Handy (SDTimes) about the primary aspects of DDD.  Read the interview here.