BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Methodologies Content on InfoQ

  • Capture - Embed - Protect, Guidelines for Domain-Driven Design

    When using the core philosophy and the practices of DDD as guidelines for software design and development, they can be summarized in three principles: Capture – Embed – Protect, Steven A. Lowe claimed in his presentation at this year’s DDD eXchange conference. Capture the domain model. Embed the model in the code. Protect the domain model from corruption from other domains.

  • Strategy for Mobile and Web Test Coverage

    Teams need to match testing with the market usage patterns across geographies of their apps as consumers are expecting smooth apps functionality across all digital channels. Here's a methodology and index for considering device/OS combinations together with other characteristics like aging, screen parameters and other testing related guidelines for data driven test coverage of the mobile market.

  • The Importance of Patterns in 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.

  • Eric Evans: DDD is Not for Perfectionists

    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 Dangers of If Statements in Domain Logic

    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.

  • Bringing the Domain Back to Software Development

    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.

  • Start with Events and DDD When Building Microservices

    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.

  • Focus on the Process, Not on Individual 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 Survey Highlights Some Trends among Developers

    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.

  • Achieving Cloud-Native Operability

    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.

  • Don't Copy the Spotify Model

    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 Anti-Patterns

    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.

  • How Agile and Architecture Parted and Finally Became Friends

    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.

  • Experiences with Behaviour-Driven Development

    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.

  • Benefits of Agile Transformation at Barclays

    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.

BT