“We need to start capturing the intent of the user. Our domain is focused on behaviours. Users should send back commands, not DTOs. The server needs to be told to do something.”, said Young, advising developers not to use editable data grids in user interface, because they are data oriented. Users should specify the intent, not edit data, said he.

“Actually figuring out what your users do and why they do it will cost money. But once you have done it, it will give you a better architecture and keep you at the same cost – or much much lower. Even at the same cost, we can get a lot of benefit.”, said Young, and suggested CQRS and Event Sourcing as the key patterns to support that.

CQRS

CQRS is based on command-query separation by Bertrand Meyer but evolved. It fundamentally requires splitting apart queries (read operations) and commands (transactions). “Treating them as separate concepts forces us to think that there are different needs for different sides”, said Young.

When we build up DTOs, we have a structural view of our data. When we process a transaction, we have a much more behavioural view. The conceptual structures are actually using completely different boundaries in these situations. So teams often come up with a half-way answer, which leads to a system that is neither behaviourally or structurally optimal. Young said that CQRS enables us not to make these trade-off s any more.

Instead of having a domain layer, we can have a thin read layer for DTOs for queries. This makes it a lot easier to optimise queries compared to using O/R mapping systems. The only knowledge people need to have to write efficient queries is a data model – not the O/R mapping technology, domain models and so on.

Separating out the reads also cleans up a lot of things in the domain layer. The repositories no longer have lots of different read methods, but only those required for particular domain. We don’t have setters on domain objects – they become purely behavioural. “Domain objects are not property buckets, they expose behaviour. We can specialise our domain layer to process transactions. The code will be clearer and the aggregate boundaries will be a lot stronger”, said Young.

Event Sourcing

Once commands and queries are separated, we can look at whether we need to use the same data source at all. When the same data source is used for transaction processing and querying, the third relational normal form is often used for both things. This requires teams to create complex queries. Splitting data sources would enable us to specialise the query data source for reading, having a first normal form model. The two data sources can then be synchronised.

To avoid inconsistency caused by this synchronisation, we need to build from one source of truth. A good option is to use domain events – notifications about what happened as the result of commands being processed.

The data model for processing transactions can also be write-only. “This is how the business thinks about changes”, said Young, “You can’t refuse to record something that happened”. We can take this even further and not have the current state of the system in the transactional storage. Understanding this enables us to restructure the transactional processing data model to just accept results of command processing. If we unify the models for transaction processing and storage, this cuts down the cost of development and maintenance.

Recording events that resulted from transactions ensures that we don’t lose any information but we can still recreate the current state when needed. This makes auditing trivial and enables a number of other things, such as replay the state of system at any time to troubleshoot or test and extracting analytics in the future that we haven’t thought about while developing the system.

Having a system structured like this requires the domain model to only to know about events. This simplifies testing – both checking for expected results and unintended consequences. Testing events would check both at the same time – any unintended change would generate more events. Integration with other systems also becomes a lot easier, according to Young, because this naturally flows around events and commands.

The event storage can also act as a queue to feed the query storage, and essentially require only a single transactional commit from the system while processing commands. This makes the system even more performant.

See other news from the DDD Exchange 2010

Related post: Two data streams for a happy web site

Tiers aren’t layers

When applying DDD, many people have in mind a classic three layer architecture, said Dahan, and there is a common assumption that the architecture layers are the same as tiers of deployment. For example, anything that’s in the business domain layer is not going to be deployed to the client tier. According to Dahan, this is the biggest mistake teams make when applying domain driven design.

A layered model is useful to tell us not to mix user interface logic and business logic or business logic and databases, said he, but the model says nothing about deployment tiers. “Starting with an assumption that layers are equal to tiers straight-jackets our implementation and colours our impression of the model thinking that we have to have data transfer objects going across tiers. If they weren’t in the different tiers, we would not need data transfer objects”, said Dahan, continuing that “almost any project I’ve seen that said that they are doing DDD made this assumption. This constrains choices and causes too many problems that aren’t related to DDD. “

Expecting to have a single architectural model for everything, teams don’t understand that they can deploy the same components to multiple tiers. Things like validation are a common cause of confusion. This causes a lot of architectural problems, that teams work around by putting in solutions such as caches. But according to Dahan, caches are often a sign that teams assume that there is a single linear layered architecture, which then causes performance problems. Many of our misunderstandings and problems we get ourselves into are related to this mix-up – layers, tiers, and what is a business rule.

Logical and physical connections are different

Another big issue with implementing DDD today is that there is an overemphasis on reuse in code. “Reuse is drilled into us in the universities and work. Even though this doesn’t reflect what we see in practice this drives us to centralise the code. Preferably in the domain model and then reuse it anywhere. Too much reuse creates an unmaintainable mess, because the system becomes hard to understand and has lots of dependencies.”, said Dahan. “When you think about domain models, business logic, validation – be very careful about how you treat it and not projecting your ideas of reuse”, advised he.

When talking about tiers, understand that you can get the exact same component, put it on another tier, and not create a dependency. The problem is when a single logical element of reuse became equal to a single physical place. This leads to lots of service calls – if it’s logically in one place it has to be physically in one place, so lots of remote calls have to happen. Equalling logical and physical locations causes too much complexity. Dahan suggested an alternative: “We want to remove these original blinders. You are allowed to deploy business logic to the client tier – that doesn’t mean you mixed business logic and user interfaces. It’s OK to take the same validation component you use on the server side and deploy on the client side. It doesn’t have to be in the same place to be logically cohesive”.

Teams also need to understand that there are different models, said Dahan, continuing “We need to understand what needs to be immediate, what means stale, and when the information can be stale, then addressing these situations with different models.”

All rules aren’t created equal

Assuming that all rules are equally likely to change is another common mistake that teams make, said Dahan. This leads to all the rules being put in the same place and the same kind of reuse applied to the same rules. Validations, calculations and workflows are not necessarily the same. For example, the requirement “the username must be unique” is common but never changes. Workflow rules (eg when a customer cancels an order, the system checks if it has been shipped and cancels if not) change substantially more. The reason for this is, according to Dahan, because these rules are actually related to a particular domain, what makes a business unique. “By virtue of the fact that all systems have the exact same requirements around username uniqueness and field length, that they are not unique for a particular business so they are not unique”, said he. These are just technical constraints, according to Dahan: “The business doesn’t care that username fields are 8 characters. Usernames have to be unique for technical reasons to be able to select customers to check details”. Rules that are not part of genuine domain logic do not have to be implemented in the domain model, suggested he, because they do not model the domain. They may be deployed to a separate tier.

Dahan quoted Martin Fowler, who defined the domain model pattern in Patterns of Enterprise Application Architecture (The Addison-Wesley Signature Series): “Use the domain model pattern if you have complicated and ever-changing rules…. If you have simple not null checks and a couple of sums to calculate, a Transaction Script is a better bet”.

Race conditions hide business rules

Another big problem when implementing DDD, according to Dahan, is that assuming the race conditions affect the domain. Giving an example of a possible race condition between the user cancelling an order at the same time as an operator asking the system to ship the same order. “As developers, we think that race conditions are business logic, so we need to write code for that”, said he, but businesses don’t understand race conditions. “We made them up. They didn’t exist in a business before we [software] got involved.” From a business perspective, a millisecond should not substantially change the domain. Businesses have existed long before computers, on paper, with concurrency problem windows not in milliseconds but in days and enormous chances for race conditions.

“But businesses still functioned. We ignore that and think that race conditions matter. “, said Dahan. Instead of solving race conditions with code, he suggested factoring time into design and talking to the business users about how the process was implemented before computers. For example, if the user cancels an order that was already shipped, charging the customer money unless they are of a particular status. The command does not fail because of a race condition, it extends to handle edge cases.

“If you think you have a race condition, you don’t understand the domain well enough. These rules didn’t exist in the age of paper, there is no reason for them to exist in the age of computers. When you have race conditions, go back to the business and find out actual rules”, advised Dahan

See other news from the DDD Exchange 2010

“Anything can be called agile, anything can be called SOA – when anything can be called that it’s no longer a useful term”, said Evans. So he wanted to offer a new, precise definition of DDD, which defies “what it is, what it isn’t, while still leaving enough space for innovation.”

Evans said that one way to define DDD is as a set of driving principles:

• Focus on the core domain — “people get distracted by technology and we want to bring that attention back to the business domain”, said Evans. Even that whole business domain is too much to focus, according to him, and DDD requires us to focus on the core, the critical, most valuable part.
• Explore models in a creative collaboration with domain practitioners and software practitioners – “we have to collaborate, not just quiz [business experts] for requirements”.
• Speak a Ubiquitous Language in an explicitly Bounded Context

Speaking about the focus on core domains, Evans said that that has to be something very specific.”We want to focus with collaborative cooperation on our core domain – we don’t want to give the same kind of attention to invoicing in most companies”, said Evans. Giving an example of eBay, he said that it is easy to assume that online auctions are the core domain but that would be wrong. He compared Amazon and eBay, and said that you can buy books in both places and they have similar features, but their core domains are very different. For eBay, it’s the rating of the seller – this is what makes eBay effective. “A star rating tells me that lots of people did business with a seller and I trust that. Developing trust between a buyer and a seller is a subdomain of online auctions, and their approach to building trust is part of the core domain of eBay. eBay would not have been today if they didn’t get that right”, said Evans.

Another way to define DDD, Evans said, is that it is a pattern language. It is a set of interrelated problem/solution pairs that have helped teams realise the principles. It also gives us a language, a vocabulary, that allows us to discuss domain modelling and design clearly. According to Evans, this is the key to enable innovation and keep the definition of DDD precise. There is a lot of innovation going on at the moment in the community, especially around architectural practices, and one of the key things for DDD in the future will be embracing those innovations. “I don’t want to say what the best way to do domain driven design is – others will present genuine advancements but none of us will be even able to understand it if we don’t speak the same language”, said Evans, continuing that he wants to hold on to the position of the final arbiter of the terminology used by the community.

The building blocks (entities, value objects…) aren’t really key to DDD, although most people initially thought that this is what DDD is about, said Evans. Having said that, he suggested that there is a lot of innovation in the community especially around aggregates, services and domain events, and that these concepts will be important for applying DDD in the future.

Related post: QCon London 2009: Eric Evans – What I’ve learned about DDD since the book

See other news from DDD Exchange 2010