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.
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.
GitLab has released the outcomes of a survey they conducted among software professionals from 362 startups from July 6 through July 27. Main highlights are developers' preference for using latest tools and more collaboration; security is high-priority, but 81 percent admitted to releasing software before it’s ready.
To drive operational maturity you need a microservices architecture, continuous delivery process, DevOps culture and platform automation. Together these four help you to transform your whole organization for achieving cloud-native operability to continuously deliver additional value to your customers.
The Spotify model can help you to understand how things are done at Spotify, but you shouldn’t copy it in your own organization. It changes all the time as people at Spotify learn and discover new things. There is no one way in which software is developed at Spotify.
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.
People stopped seeing the need to define the architecture or do software design due to incorrect interpretation of the agile manifesto, argued Simon Brown. Many software developers don’t seem to have a sufficient toolbox of practices and the software industry lacks a common vocabulary for architecture. A good architecture enables agility with just enough up front design to create firm foundations.
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.
Increased throughput, reduced code complexity, less production incidents, shorter deployment cycles and higher happiness in teams; these are some of the benefits that the agile transformation at Barclays has delivered. Within the first year of the transformation, which is based on Disciplined Agile, more than 800 teams adopted agile making this one of the largest agile implementations.
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.
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.