Session

Domain Prototyping or Design Is How It Works

When we design a system from scratch, especially complex distributed systems, with microservices and/or Big Data pipelines, we have to make a series of important tactical decisions regarding the structure and information flow within our domain. If we assume boundaries in the wrong place, or forget or omit important aspects of communication, we can end up with brittle services, performance issues, and needlessly coupled modules and components, which are painful to maintain and deploy. Some of those aspects are hard to discover upfront, and even with great experience, it's not unusual to get the first design at least partially wrong.

One way to minimize the consequences of those decisions, and to verify our initial assumptions, is to start implementation not with a full architecture in mind, but rather with the smallest possible footprint: A plain, but fully operational prototype of the domain model, which we can stress, observe and explore - and change easily, if we run into problems. This way, we can actually see our design work, and gain valuable insights. As a side-effect, we can also deliver customer value much earlier, by using the raw domain model to power UX/UI prototypes - replacing fakes and click-dummies with a working application.

Using concrete examples, I will demonstrate how combining Domain Driven Design with the practices, heuristics and principles of Software Crafting can highlight difficult or problematic choices, improve fundamental architecture decisions, and ultimately lead to better and more sustainable software systems, long before we get sidetracked by the additional complexity of host environments and deployment pipelines.

I presented this as a 2 hours hands-on at DDD Europe. There are no slides, but there is a github repo with exercise instructions, which should convey the idea.

It turns out, 2 hours are really not enough for most people to grasp and apply the concept - and that detriments the value of a hands-on significantly. That is why I chose to turn it into a talk, instead: I can present some examples and give a “guided tour” in much less time.

This talk is for advanced practitioners.

Tobias Goeschel

Senior Solutions Architect at AWS

Bad Waldsee, Germany

Actions

Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.

Jump to top