March 2009 - DDD on the Web

Learning BDD I have been trying for some time now to understand what the BDD exponents are talking about. I'm sure that Scott and Colin Jack are sick of me asking questions on BDD. This is pretty much a journal of my understanding. It might help others on a similar journey, hence the reason for blogging it. I know a number of people have been asking me about BDD recently at community events, so this is an attempt to share where I am in understanding so far. Be aware that there may well be misunderstandings here. I'm not claiming any kind of authority for BDD. Hopefully more experienced practitioners will help me to correct any mistakes. Please use the comments. As my understanding improves I'll keep you posted. For now be aware this is really a 'notes to self' blog. The approach of this post is mostly historical. That is mostly because my current understanding of BDD is that it is an opinionated packaging of ideas from STDD, ATDD, and TDD. So I find it helpful to understand the ideas it is built on and where current skills form a part of the BDD mix. A key resource for me in understanding BDD is Scott Bellware's Code magazine article on the topic . The opinions here are my own though. Behavior Driven Development...

Here’s a basic test; looks simple right? Well, that’s because it is. A new Order is given three different order items, each with a quantity of one. We assert (using nunit) that there are three OrderItems, then RemoveAllItems and assert that there are zero. [ Test ] public void An_Order_should_be_able_to_remove_all_items() { var product1 = new Product ( "part1" , 10m); var product2 = new Product ( "part2" , 20m); var product3 = new Product ( "part3" , 30m); var order = new Order (); order.AddOrderItem(product1, 1); order.AddOrderItem(product2, 1); order.AddOrderItem(product3, 1); Assert .That(order.OrderItems.Count(), Is .EqualTo(3)); order.RemoveAllItems(); Assert .That(order.OrderItems.Count(), Is .EqualTo(0)); } If you know where this is going, you’re at least one step ahead of me when I wrote the RemoveAllItems function. It does exactly what it is supposed to do, and this test passes. There’s more than one way to implement the RemoveAllItems function and initially I chose a bad one. The following is the original implementation. Looking back, it’s obvious that it is wrong, but at the time, it must have been “the way” to do it. public class Order : IOrder { private IList < IOrderItem > orderItems;...

How a person behaves during the positive times and upswings in life is not a good indicator of that person’s values and principles. Find a person in a difficult time, a low point in their life – someone who has been working excessive hours in a highly stressful job; is having serious family issues or has lost a loved one; lost their job and doesn’t know how to make financial ends meet; etc etc. Look at the behavior, the attitude, and the outlook on life and situations that this person has. That’s where you’ll find the real measures of that person’s worth, and their values and principles. Values and Principles In Software Development If you’re a software developer who believes in the current Test Driven Development, Behavior Driven Development, SOLID principles, Domain Driven Design, yadda-yadda-yadda… what do you “fall back” into when times are tough and deadlines loom?  Do you allow entropy to set in and revert to old ways? Do you start to code-first and think about tests later? Do you follow the tried-and-true processes and methodologies of your team? Do you throw process out the door and kick it into cowboy coding? When push comes to shove, what principles do you follow and what do you truly value in your software development...

Domain driven design has become a very prominent way to develop software. A central domain model is used by all participants. To the end user it is a representation of the real  world. To the coder the model is a class model, working with the real domain world boils down to instantiating objects from these classes. In meetings we find ourselves often discussing a Visual Studio class diagram. Nothing fancy, but it works quite well. The domain user recognizes her entities, their data and behavior, the developer recognizes his classes, properties and methods. In DDD these domain objects interact with the database through repositories. The methods of a repository return (sets of) domain objects as read from the database or accept domain objects which will be persisted to the database. nHibernate is a wonderful tool to build these repositories. All you have to do is define a mapping between domain classes and databases tables and nHibernate will take care of the tedious sql stuff. As a bonus you get a nice API for querying. But there are reasons not to use nHibernate. Learning curve. In some teams the jump from sql scattered between the tags of a web page, stored procedures and wherever else to an O/R mapper is to big. Getting all...

As Jan has decided for all of you , I'm just going to continue with these small and concise posts. This time it will be the first post in a series about modelling. But before we begin, it's probably best to get on common foot here on what a model is, as many people have different opinion's on that. A model is NOT a diagram, it’s the idea that the diagram is intending to convey. It’s a rigorously organized and selective abstraction of knowledge as it appears in the collective minds of the team members. So a model is in your head, not on paper. (You will obviously need reflections on paper in order to communicate with one another) As you probably know allready, a Domain Driven Design is based on a domain model. So a domain model is per definition the collective understanding of the domain. This model is the backbone of a language used by all team members, which is therefore rooted in the business, not in IT. The model and the heart of the design also shape each other, they are linked and understanding the model should allow you to interpret the code. But always keep in mind that the model is distilled knowledge, an abstraction, that has been agreed upon by the entire team and that captures how we choose to think about the...

Domain-Driven Design (DDD) is a collection of principles and patterns that help developers craft elegant object systems. Properly applied it can lead to software abstractions called domain models. These models encapsulate complex business logic, closing...

Some people had asked for a video of a talk about some of the things that have come up here. Here is a link to the talk I did for EuroVAN last month. It covers some material on cqs and other things... http://vimeo.com/3171910 I have to say that it was...

A recent paradigm shift I have been trying to make is to using messaging patterns in my project. One impact of this shift has been a more granular approach to various commands against the domain which somehow changes its state. While I do my best to stick to DDD (Domain Driven Design) modeling patterns and concepts I confess I slide into a CRUD based approach to various actions in the system - lots of data in, lots of data out. This is partly due to the nature of the requirements and partly due to lack of creative thinking regarding what business rules should be enforced on the domain. As I started to examine where my weak points were in my application I realized I was doing an awful lot of mapping between view objects and domain entities within the Application Service layer which was being called by my Controllers in the web app. This is fine for simple cases but collections of value objects or cross-aggregate references can soon result in too much conditional or procedural code. Then I came across this post by Udi Dahan about getting away from CRUD mentality into a more DDD approach. I had read this before but I didn't "get" it so much. Particularly revealing to me was in the comments where Udi explains a method which...