At QCon London, Jonas Bonér, CTO at Lightbend, presented “From Microliths to Microsystems”, and explored microservices from first principles, and discussing the architectural style in the context of distributed systems. Key takeaways included: avoid building ‘microliths’, and instead create systems that are resilient and elastic; and practice events-first Domain-Driven Design (DDD).
There are lots of patterns outside of Domain-Driven Design (DDD) that are important to know, and they will help you design better systems, Cyrille Martraire claimed in his presentation at the recent DDD Europe Conference in Amsterdam when discussing the importance of patterns.
At the microXchg conference in Berlin, a group of software development practitioners shared their latest learnings about the microservice architectural style. Topics discussed included functional service design, integrating DDD and REST, creating microservice-powered websites using transclusion, choosing a microservice platform, and the organisational and people impact of microservices.
A problem with Domain-Driven Design (DDD) since the beginning has been the too common hunt for perfect designs, but DDD is not for perfectionists. In order to stop that hunt you need to have some idea of how to create software that is well designed, yet not perfect, Eric Evans noted in his presentation at the recent DDD Europe Conference in Amsterdam.
The if statement found in most programming languages has two major roles, validating input to protect the domain from erroneous data, and for dealing with business logic inside the domain. Unfortunately, we spend too little time managing the risks from a business or domain perspective, Udi Dahan claimed in his presentation at the recent DDD Europe Conference in Amsterdam.
If you read the business press of today, you will find that the business side of the world sees IT as an impediment that holds them back. To overcome this, we need to shift focus from the machines to the domains and start reading and learning about the domains we are working in, David West noted in his presentation at the recent DDD Europe Conference in Amsterdam.
Domain-Driven Design (DDD) is a great technique bringing designs closer to the domains we are working in, but too often we make early decisions with a focus on structure, which is not the intention of DDD. Instead we should start with the events in a domain, Russ Miles claims when describing the advantages of going “events-first” when building microservices.
The key to success when working with a microservices based distributed system is to focus on the distributed process as a whole, not on the microservices themselves. The services are the least important part, Eric Ess claimed at the recent Microservices Conference in London, in his presentation on how to monitor distributed processes at jet.com.
Behaviour-Driven Development (BDD) can help in improving how business stakeholders and software developers communicate with each other, but there are some common anti-patterns when using Cucumber to run the automated tests, which Aslak Hellesøy, Matt Wynne and Steve Tooke described in a recent discussion.
Behaviour-Driven Development (BDD) recognizes that software development is fundamental to businesses of today and helps to improve how business stakeholders and software developers communicate with each other, Kevin Smith claims in a recent blog post about his experiences working with BDD.
One of the hardest problem when creating and developing microservices for an enterprise is their data. Analysing the business domain using Domain-Driven Design (DDD) and reason about what your data represents will help in achieving a microservices architecture, Christian Posta claims in one of a series of blog posts about microservices implementations.
Increasingly, software developers have the ability to not only maintain and architect code, but extend their expertise to providing direction to the business. By using domain driven design, developers can discover customer behaviors and recommend practices that change the nature of the business.
Although a monolith can be modeled in a respectable way, often they are turned into a big ball of mud. This is caused by multiple domain models becoming entangled within the monolith, and in Vaughn Vernon's experience this can happen within a few weeks or months, he claimed in a presentation at the Scala Days conference earlier this year.
Juval Löwy has pioneered a method of building service-oriented applications in which each class represents a service onto itself. While these applications may initially seem like 'class explosion', they are actually the product of a truly decomposed system; one that has been properly analyzed and designed. Juwal explains his intent and describes how development teams can improve from this process.
In the context of Domain-Driven Design (DDD), Event Storming is incredibly useful and valuable, Dan North claimed in his presentation at the recent DDD eXchange conference in London, explaining the basic mechanics of Event Storming and sharing his experiences from modelling different systems during the last few years.