We Design,
Build and Run
Software

A product must provide useful functions and a satisfying experience through its usage. Good design emphasises the usefulness of a product whilst disregarding anything that could possibly detract from it. Good design clarifies the product’s structure. Better still, it can make the product talk. At best, it is self-explanatory.

We make capabilities by separating concerns and finding proper abstractions for the problem at hand. Lisp: A Language for Stratified Design

Design are always compromises given a problem to solve and some constraints (duration, price, environment, etc.). We always make our decision explicit and tracked through Decision Records. Good design should focus on the domain problem space and provide good solution with technology, not the inverse. The software should have the right features to solve the problems at-hand not more.

Modularity is the hearth of a design: what's a module's core responsibilities and the contracts its exposes and consumes with its environment? dependencies and interactions between each modules constitutes the whole system structure and behavior.

In DDD we trust and do everything possible to ensure that software reflects your business domain. Too often, software becomes a center of complexity and it is difficult to maintain it beyond the original development team. We produce sustainable software that will adapt to your domain and limit the impact of turnovers.

Web technologies evolve very quickly, and probably faster than your business domain. Therefore we always implements hexagonal architecture to decouple the domain, application and infrastructure concerns, so that the product can evolve as the technologies advance without rewriting everything. What's matter is your domain, not technology.

The feedback loop is a central aspect of our developments. Without it, delivery time to production increases, assumptions become less validated, specifications become unclear and development costs increase. We implement and maintain this feedback loop first and foremost, whether with the business teams or through the users in production, in order to quickly build the right product.

We use the Clojure language on the Java and Javascript platform because it makes a huge difference in our ability to ship software that is simple, performant and reliable. The REPL allows for fast feedback loops, the ecosystems of the platforms are the richest and the functional and immutability features of Clojure makes it a breeze to solve complex problems. Read more...

Each module must expose the Command, Query and Events it consumes and exposes through API and Messaging, leverage synchronous and asynchronous communication protocol, orchestration or choreography. We have at heart to elaborate this protocol so that it reflects as closely as possible your business domain. We use distributed systems as a last resort to solve organizational or operational concerns and would always choose the simplest deployment solution given the context.

We test our solutions by rapid prototyping based on real data. We eliminate design errors as quickly as possible and validate our assumptions. We use workshop for efficiency and to save time with developers. Workshops also facilitate and structure the domain exploration and specification of the software to built, with non developers.

We extend our software development tools and principles to the infrastructure that will support your products. We consider that the infrastructure must adapt to the application needs, and not the opposite. Furthermore, this infrastructure must be maintained and driven by code and not by a sequence of scripts or manual actions because each operation must be maintainable, scalable, repeatable and automatable. Whether delivering to production or creating an environment, it happens without any effort.

Observability is an essential element of the feedback loop, it allows better knowing of usages and behavior of the running system. Observations support and impact every product decisions (hint: Domain Events are great for that).

We explicit operational requirements through Architecture Decision Record and build observable metrics on those requirements.