best_practices design development events products springone_2gx video

SpringOne Video: Domain Driven Design Using SpringTrader

Domain driven design (DDD) is about dealing with complexity in software.

Complexity causes problems—confusion, rework, increased risk, project failure, and more. If you’ve ever had to work with someone else’s bowl of spaghetti code, then you know that domains and design were largely ignored.

Over time, lack of a well-designed domain leads to 1000s of lines of unorganized code, difficulty in making changes, problems with integration, an increase in the cost of applications, and limits the value delivered by software. What causes projects to lack well-designed domains? Certainly, there are cases where software engineers don’t care about design and just want to bang out code. However, it seems that the people who drive requirements, business decisions, and software investments are often the culprits—the hurry-up mentality of modern business practices can push software developers to cut corners, misunderstand requirements, and make mistakes. If you’ve ever been rushed through software design or read about the defect creation/correction cost diagram in Steve McConnell’s Project Software Survival Guide, then you know that a poorly understood requirements, architecture, and design decisions are costly and inhibit future agility.

SpringOne 2GX

In a talk from SpringOne 2GX 2012, Vaughn Vernon, author of Implementing Domain Driven Design, and Wes Williams, Senior Consultant with EMC, explain how domain driven design is used to extend a cloud-based, distributed architecture using SpringTrader (previously called Nanotrader) as an example. If you aren’t familiar with it, SpringTrader is VMware’s reference architecture for a high-performance, trading application based on the vFabric product suite and uses Spring MVC for both web and mobile UI’s, Spring Integration, RabbitMQ, GemFire, SQLFire, and more.

THE BACKGROUND ON DOMAIN DRIVEN DESIGN

According to Martin Fowler’s Foreword of Eric Evan’s book, Domain Driven Design, “the key to controlling complexity is a good domain model, a model that goes beyond a surface vision of a domain by introducing an underlying structure.” Domain driven design, like other good design processes from architecture, graphic design, industrial design, or user-interface design, is a way of thinking about and organizing the problem and solution. In software, projects often lack enough design thinking and organization because design is under-prioritized. Good design takes time, and we don’t apply enough engineering discipline to our plans. As an example from another engineering discipline, you wouldn’t build a skyscraper with the seventh floor first, build the building to realize the contractors had 3 different meanings for the word “lobby,” then go back to decide to change the floor plan for the foundation, then expand the 25th floor 150 feet outside the walls of the building, then connect the HVAC and bathrooms your skyscraper and another building—but we regularly do this type of thing in software engineering.

The domain driven design approach provides a way to connect stakeholders, users, designers, and developers through good communications, and the core is a solid domain model. As an example, domain modeling brings together the concepts and language of the key stakeholders driving requirements, such as a sales operations team, and effectively combines this vocabulary with the Java development team’s organizational models for developing sales operations software. As a reminder for those who haven’t used the term in a while, a domain model is a conceptual model of all the topics in the scope of the solution or problem—entities, attributes, roles, relationships, and the meaning of their vocabulary. The domain provides direct input to how developers organize and write code. In UML, this is often referred to as a class diagram.

Why does the domain model matter? Well, what happens if you are 20,000 lines of code into a project, and, in the first UAT, you discover that there are actually “holds” and “orders” instead of just “orders.” Then, you also realize that holds and orders have significantly different behavior. One of two things happens a) the development team scrambles over nights and weekends to fix it or the stakeholders have to accept a product with lower quality and functionality.

KEY POINTS FROM THE DOMAIN DRIVEN DESIGN PRESENTATION AT SPRINGONE

vFRA_HeaderWilliams, the first presenter, has worked in software, largely for financial services, since 1981 and begins the presentation with a question—what happened to software craftsmanship? To answer, he explores the evolution of visual basic property sheets, the abuse of the JavaBeans spec, the lack of design teaching in colleges, the environment of outsourcing, low retention rates of software engineers, and corporate incentives to get a bonus based on hitting code milestones even when the quality isn’t there.

After sharing a personal example of how code turns into spaghetti, Williams shares a diagram of the SpringTrader architecture and points out where algorithmic trading services will be added with a domain driven approach to design. He shows how VWAP analytics will be added via a new trading service, shows a quick demonstration, and shares that the vFabric Reference Architecture code is available on GitHub.

SpringTrader Reference Architecture

Vernon starts his portion of the presentation by elaborating on the essence of DDD. He explains the two key fundamentals that help set the common foundation for domain driven design:

  • Bounded context—This concept defines a shared definition of the software. For example, can we all call an order the same thing and have the same meaning when we use the word order or account, eligibility, enrollment, etc. The bounded context provides an explanation of something the team agrees to define, to place in context of use, and to set boundaries. This definition ultimately provides specific expectations about how classes, code, and database schemas apply and helps to ensure consistency of language and reduce confusion.
  • Ubiquitous language—This concept implies a common language for describing the bounded context, business requirements, and supporting the system view of the domain model. It should be used by both business and technical team members to connect all the activities of the team with the software. For example, since we have set the bounded context for order, both business and technical teams should use the same definition consistently and understand what each other means.

Vernon goes on to apply DDD to the SpringTrader architecture and also applies it to the dependency inversion principle, hexagonal architecture, service oriented architecture, command query response segregation, event-driven architecture, and event sourcing. He explains aggregates, domain events, value objects, and more. Lastly, Vernon goes on to explain how the algorithmic trading domain was added to the SpringTrader domain.

TO LEARN MORE:

Related Articles