BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Reflecting on Top-Down or Bottom-Up System Design: Vaughn Vernon at MicroXchg Berlin

Reflecting on Top-Down or Bottom-Up System Design: Vaughn Vernon at MicroXchg Berlin

Leia em Português

This item in japanese

Bookmarks

Should software design be driven by a top-down or bottom-up approach? Vaughn Vernon asked the question in his presentation at MicroXchg Berlin, where he discussed different approaches to software design, the actor model, reactive domain-driven design, and the importance of an emergent architecture.

For Vernon, founder of vlingo and author of the Implementing Domain-Driven Design book, the two most important concepts in Domain-Driven Design (DDD) are the bounded context and ubiquitous language. There are additional strategic and tactical modelling tools, as well as other tools, but when he discusses DDD, those two concepts are what he is thinking about. If your DDD perspective is about entities, value objects, aggregates and things like that, he suggests that you have missed the essence of DDD.

DDD is also about learning. If you start in a software project without the approach that you need to learn, then you just use DDD as a set of tactical approaches to create objects and functions, and you will likely end up in a mess. Too often Vernon has experienced even very experienced architects and developers start in new projects from the perspective that they already know everything and try to solve all problems on their own.

Learning begets knowledge and knowledge changes everything.

In Vernon’s experience there are a lot of strong opinions whether a system should be designed top-down or bottom-up, sometimes to the extent that it’s claimed to be dangerous to do the wrong thing, leading to a messed-up system. For him though, the risk lies in trying to know everything up-front, which he relates to waterfall thinking.

For Vernon, both top and bottom perspectives are strategies for learning and knowledge ordering. Both can be quite useful — they are just different styles of thinking. Top-down thinking is mostly about what you already know. You are stepwise decomposing problems with each problem looking like a black box — the content is unknown. But, at some level you will get stuck and then you must switch to a bottom-up perspective and try to discover what you don’t know. Now you are creating small pieces of software, that can be actors, which eventually will become subsystems in a larger system, something Vernon sees as an emergent approach.

Vernon compares a top-level perspective to using strategic design. You start by looking at the information exchange between subsystems, which leads to the published language of a bounded context. This will in turn lead to the mental model spoken by the team working in this bounded context. This mental model is rendered as the ubiquitous language within the context. This gives the following working order:

  1. Information exchange
  2. Published language
  3. Mental model spoken
  4. Ubiquitous language

If you instead take a bottom-up perspective, you are thinking in terms of the model — a tactical design approach. A team now has to discuss what they don’t know, thereby creating a mental model and a ubiquitous language. The ubiquitous language will then have an influence on the published language. Finally, you can exchange information between subsystems using the published language. This gives an almost eversed working order:

  1. Mental model spoken
  2. Ubiquitous language
  3. Published language
  4. Information exchange

Vernon emphasizes that both perspectives are important, but if you are thinking about bounded contexts with their ubiquitous languages you are probably taking a bottom-up approach. Then it’s important to learn what the core domain within your whole solution in, otherwise you may very well put your efforts in the wrong place. If you need to take a top-down perspective at some point, you can define an interface as a placeholder for something you do not yet understand how to communicate with. Later, this placeholder can be replaced by an implementation in a bounded context. As you do that, you also shift to a bottom-up perspective because you now need a deep understanding of the domain model within that context.

For Vernon, a bottom-up approach is also an emergent approach which leads to an emergent architecture, and for him is the same as lean architecture or agile architecture and design. Trying to make your architecture immovable will not work; he believes that you will either adjust your architecture, or fail. If you know what you are doing, the architecture will emerge, and he notes that there are several architectural styles and patterns that can help you succeed. One architecture style that fits the emerging approach is the hexagonal architecture, created by Alistair Cockburn (also known as ports and adapters and clean architecture). The core in this style is the domain model, surrounded by the application layer. The outmost is the infrastructure layer that provides input and output through ports and adapters. Vernon notes that one primary advantage of this architecture is that every adapter can be created and tested in isolation. You only have to understand an adapter when you actually need it, making this a very agile and emerging architecture. One example is deciding which type of data storage to use, which can be delayed until you learn more.

He concluded by referring to vlingo, the open source DDD-friendly reactive platform based on the actor model he is working on. He believes it fits well with the ideas he expressed in his presentation.

Most presentations at the conference were recorded and will be available over the coming months.

Rate this Article

Adoption
Style

BT