Our Approach

Adaptech's approach leverages a variety of modern best practices which allow business and technical teams to combine their expertise and perspectives to model software quickly and easily while creating a shared understanding of what they are building. The product specification then also serves as both architecture and development plan. Adaptech's team can provide architectural guidance, legacy migration planning or software delivery as needed.

The Core Principles Behind Our Approach:

Domain-Driven Design (DDD)

An approach to modelling and developing complex software such that the resulting software reflects core concepts of the business. DDD's underpinnings are:

  • That the project’s key focus be on the core domain and domain logic
  • Complex designs must be based on a model
  • Collaboration between technical and domain experts is essential to clarifying what needs to be built

Event Storming

This is the approach we use to model complex business flows. It is geared toward projects that leverage Domain Driven Design and Event-Sourcing but provides insight no matter what approach you use. Along with outlining your existing system, new features and where they will fit in, the approach fosters team collaboration and a sense of a shared mission and clarity.

Event Sourcing

An approach in which application state is recorded as a complete series of events based on all of the events that have taken place within the domain. These persisted events can re-establish the state of the actors within the domain at any point in the past. Event-sourced systems persist events rather than state and offer the following benefits:

  • Simplicity: Persisting events rather than state avoids the complexity of ORM
  • Performance: Events are simple, self-contained and immutable lending themselves to append-only operations
  • Flexibility: A series of events can be "projected" into any "view" at any time
  • Business Value: Events that happened in the past can provide new insight in the future. By saving all events you can query the system at any point in the past and answer historical business questions as the come up
  • Easy Integration: Events integrate easily with other systems due to low levels of coupling

CQRS (Command-Query Responsibility Segregation)

CQRS is the separation of one objects into two. It’s an approach that separates reads from writes and allows them to be scaled and performance-optimized independently. This offers the following benefits:

  • Scalability: In most systems reads outnumber writes by a wide margin. CQRS allows you to scale each separately and appropriately
  • Simplicity: The write and read model can be different avoiding the complexity and contradictory nature of handling reads and writes through a single model
  • Flexibility: Separate reads and writes makes it easier to change a system with greater confidence and more predictable effects
  • Business Orientation: Commands very clearly reflect business-related actions. Using CQRS and DDD together can result in applications that are easier to change and maintain.
  • Easy Integration: Events integrate easily with other systems due to low levels of coupling

Event-Driven Architecture

A pattern that advocates for the production, detection, consumption and reaction to events over other forms of integration

Separation of Concerns

A design principle that ensures modularity such that each defined section of the software being written deals with separate concerns

Do One Thing Well

A cornerstone of UNIX development which advocates for the development of highly-cohesive and small applications

Loose Coupling

An approach that advocates for components being as independent of one another as practicable

High Cohesion

Cohesion describes how closely related components of functionality are with a specific module. High cohesion results in software that is robust, reliable, reusable and easily understandable