Categories

DDD eXchange 2009

DDD eXchange was last Friday. The Event started with Eric Evans’ keynote on strategic design and responsibility traps. Strategic design is covered by almost the last 40% of Evans’ book, and it was a good opportunity to hear an overview of Evans’ thoughts about the subject. Most of us know by experience know that, not all of any large system will be well designed. However, Evans argued that trying to make all parts of a large system equally well designed may lead the whole system become badly designed.

He gave an example of a company that wanted to switch its legacy system with a better designed one, using more recent technology. In most of the scenarios like this, which lead to fail, the switching process it planned to be accomplished in around 3 phases with around 1 year for each phase. These phases are building the infrastructure, transferring the legacy code over this structure and adding the new features over those layers in the final year. However, transferring of the legacy code generally does not turn into be as easy as it was thought to be. The complexities in the legacy code are there for a reason, and redesigning those complexities needs much more focus on the domain design.   Also it is possible that by the time the project reaches phase 3, people will have forgotten what was the main focus of the project, furthermore, the business will continue evolving and the some of the requirements will need to be changed.

Bad goal: Switching off the complex legacy system and building a nice, well organised system from scratch (Image taken from Evans' presentation)

Bad Goals

The first bad goal is completely switching off the legacy system. Evans stated that, unless the current system is highly expensive, re-designing it is a bad idea, because things will never be as perfect as an imaginary nice pyramid. Therefore, the agile kind of solution might come to mind as refactoring. This leads to think with the concepts of the old system while building the new system.

Hacking is another option that might come to mind. This means only adding the new features instead of changing the whole design. As a result, this adds more complexity into the system. This is also the approach that is generally followed after the two bad goals mentioned above fail. In the end, all the methods are likely to result in a final system that is similar to the one that was supposed to be replaced. According to Evans, all these approaches underestimate the importance of the design.

The Core Domain

There are Generic Subdomains, that do not require you to innovate something (i.e. Accounting). Supporting Subdomains, things that are specific to your business, and the Core Domain, which can not be bought off the shelf. It is important to understand the difference between the core domain and core features. For legacy systems with highly complex connections within it’s components, hacking seems the best approach for adding core features, because this approach leads to immediately working on the core.

Responsibility Traps

Evans describes irresponsible programmers as the ones who cause downstream cost and harm while not being recognised because they deliver the required features fast. It is a common mistake that development teams are based on a few irresponsible developers and some other developers who are supposed to clean the mess. As a result of falling into these traps, there are no sexy new capabilities, and hackers get well recognised while the design people are not regarded enough. Furthermore, leveraging weak programmers with sophisticated frameworks or platforms is an illusion. Those tools should be used to leverage your own team, who knows the system.

Context Mapping

Is it possible to just focus on the core domain? There are always multiple models. ‘Context mapping’ addresses the fact that different groups model differently. In a similar way to different people touching different parts of an elephant have different concepts about an elephant, different design people can have different models about different parts of a system and this is okay, because all those concepts can be bound together in a meaningful way to form a domain model. Evans suggests that we should not focus on building complete pictures of a system

Using an Anti-corruption layer for focusing on the core domain. (Image taken from Evans' presentation)

Another bad goal is to decide to use the same model in every team for every project. Using a ubiquitous language within an embounded context is the solution proposed by DDD. Here comes the term Context Mapping into practice. We should have a single and unified model within each context. Some of the contexts can be “big balls of muds”. Anticurroption layers are used to separate these contexts from the outside world. It is an interface design to support our model.

Anticurroption layers can be used to only focus on the core domain by proving the required functionalities from the legacy system. Practitioner Reports on the DDD website includes experiences of appliying DDD, along with a report about implementing an anticurruprion layer.

Evans listed the good goals as: stabilising the legacy system, clarifying the context map, deliver early, produce enthusiastic business sponsors, focus on the core domain and to create a platform.

Thick translation layers, inelegant (but stable) legacy and supporting domains are ugly, and should be avoided.

By taking these advices into account, you can be the hero for a change in your project. More information about strategic design can be found at part 4 of Evans’ DDD Book.

Context Mapping in Action

Next talk of the day was by Alberto Brandolini about Context Mapping. He explained the way he performs his profession, and his experiences of applying DDD in his previous projects. He also talked about various “mentors” who inspired the way he determined to approach problems, like Mr Wolf, Sun Tzu and Franco Begbie! He described each project as a limited resource game, where the resources are: Brain cells, time, developers and skills. Those are the limited resources other than money.

In the first scenario he explained, there was a freshly written legacy core however it was badly written. Furthermore, the analysis team was separated from development, and there were different development teams in different cities. Finally, it was forbidden to be in interaction with users. They started with producing an anti-corruption layer for the core domain and working on its features, however, after some time, because of the lack of effective communication between teams, contexts started to get into each other and it was hard to share a common vision. In this particular situation, exposing the truth about the architecture allowed the management of organisation to understand the problems and take some essential and necessary steps to prevent potential upcoming problems.

The Second “Strangelove” scenario was a large government project with a great development team where many actors were involved and the domain was not the primary focus. It was about connecting present components. Like the previous project, they did not have good conditions for applying DDD. They had to work with another team from a different company that was responsible for security and the boundaries between the two teams were not well defined. Soon after, the relation between  two teams turned into fighting. As solution, they defined an anti-corruption layer for their project. Then they started doing continuous integration while publishing their steps reliably. They focused on the other team’s needs and tried to form an effective partnership. 2 years later, the system was working perfectly but it was not doing the right thing, because the team was not focused on the domain enough.

1 comment to DDD eXchange 2009

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>