Author Archives: alokmishra

Alok brings experience in engineering and architecting distributed software systems from over 20 years across industry and consulting. His posts focus on Systems Integration, API design, Microservices and Event driven systems, Modern Enterprise Architecture and other related topics

10 steps to DevSecOps: Engineering your software better

My top-10 things to do when starting out on a project to improve code quality and security through DevSecOps About 7 years ago I was frustrated with the industry practices where it took us 6 months to provision environments, projects were delayed due to environment issues, manual deployments (UI based code uploads), long deployment times…More

Technology Service Modernization (Part I): 3 Approaches to Modernization

Welcome to 2022. While I was in a blogging hiatus, my time was spent closing out conversations with business and technology leaders looking to modernize their technology solutions as they were looking to adapt them new market needs and challenges. I thought Web3.0 was the big buzz word but it looks like Modernization is the…More

On Measuring Software Design

Good design leads to good engineering quality and products that are useful, fun to use, simple, efficient and safe. But what is a good design? Is it purely subjective and opinionated or are there specific attributes of a design that lend themselves to introspection and measurement? Why measure? Measuring helps us quantify something at a…More

Sustainability as a key Software Architecture Choice

As an architect my day-to-day involves helping my clients solve wicked problems while delighting their customers and staying profitable and sustainable as a business. I do this by obsessively reasoning about software architecture and design choices. As an architect circa 2021 growing climate crisis has me concerned especially as the software industry and the solutions…More

The Domain Stories Series: Search Story

A common story we often hear is related to searching for information. This is a powerful capability to provide through your technology services as the user is keen to interact with your offering and the richer and performant it is, the more value the consumer draws from this. Google it! When analysing the search story,…More

Domain Model != Data Model

One of the smells when practicing DDD (Domain Driven Design) is when you are presented with a Data Model (extracted from an existing set of tables or constructed through rigorous but confirmed hypotheses) and asked to consider this as your Domain Model Domain Model is not the same as a Data Model This is an…More

Business Services and APIs: 101

Business oriented service design and implementation is becoming increasing popular with organisations looking to move beyond traditional systems integration led services. This top-down approach needs to start with business domain owners and their processes, documenting the core and supporting business capabilities they present to their customers so that they can be analysed to produce technology…More

DDD Anti-patterns: 5 things we get wrong with Domain Driven Design in practice

As a software architect I have been using various design techniques including Domain Driven Design (DDD) which has been incredibly useful for building APIs and Microservices and for strategic architecture consulting engagements requiring discovery/mapping of socio-technical organisation structure and in documenting an API strategy I have also been training architects across organisations to understand and…More

How does having an API Catalogue accelerate Business Integration?

An API Catalogue is a view of your business products expressed as technical services as visible to internal and external consumers to facilitate fast and self-service integration to deliver richer value to end customers and deliver it faster An API Catalogue lets your customers view and interact with your product brouchre A catalogue item can…More

Mapping Business Capabilities to Services

One of the key questions around API strategy we get asked is how do we map business capabilities to services. An approach is to use domain driven design and build domain services, in this post we will look at what this looks like Capabilities Businesses domains offer capabilities. Given domains are classified into core, supporting…More

Iterative Domain Model Design: How to stay autonomous

One key question that I hear with Domain Modelling is how do you know if you have your transaction boundary right (so that you build the right aggregate)?  Hidden in this is another question – what if we got our domain aggregate wrong? We can take this further and ask In an agile world, given change…More

Ubiquitous Internet of Things: How ESP32s are changing the game

I have been tinkering with IoT devices for over 10 years now, starting with micro controllers with ethernet ports (later bulky wifi-shields) that were cumbersome to scale out and put onto things. For a true internet of things, we needed low-cost, connectivity enabled, sensor packed devices we would attach to things easily and then read…More

Domain Driven Design (DDD): Core concepts and Enterprise Architecture

If you are building or designing APIs, Microservices or integrating systems then Domain Driven Design (DDD) offers a valuable design technique for mapping business domains to build software services of value Using DDD is incredibly useful when designing services because it helps you rationalise the granularity of your software, the ownership boundaries and model interactions…More

Single view of Customer from Distributed Software: Part II

In the previous post we discussed how to identify some of the challenges around a single view of the customer. In this post we look at some of the ways we manage customer contacts in the enterprise systems and relate them to Domain Driven Design context mapping Patterns 1. Separate ways: We all have our…More

DDD Context Mapping By Example: Customer Management and Customer 360

In the continuation from the previous post, here we look at how to do context mapping from sample real-world examples. In this post we look at how to model Customer Management from a customer support perspective and how Customer 360 would look like as a context map With this post, I hope to give you…More

DDD Context Mapping by example: Policy Management

DDD context mapping can be confusing without real-world examples. In this post we will model sample implementations for two scenarios using bounded context maps and learn to analyse the relationships from the maps. With this post, I hope to give you a fair idea of how to do apply DDD into build good distributed features…More

Single view of Customer from Distributed Software: Part I

Customers are at the heart of every business model and industry. It is therefore no surprise that throughout my journey as a consultant I have witnessed initiatives eventually lead to one trying to get a single, unified view of the customers at they appear in various IT systems The challenge is when technology implementations focus…More

Strategic DDD and Context Mapping for Architects

Conway’s law says the structure of our organisation guides how we build software and this holds specially true today as we build distributed software services rapidly and at scale. So how do we map business domains, technology services, engineering teams, communication patterns, dependencies as enterprise architects and integration domain architects? The problem 1. Growing disconnect…More

User Journey, User Story vs Domain Story: What’s the difference?

While running DDD workshops with clients, I have had this question come up several times – “What is the difference between a Domain story vs a User Story?” Here is a quick look at differences: User journey story: Is a technique for describing how the user interacts with our business (and business systems) over time…More

Understanding Error Handling in Integrated Solution: Making things robust

Integration engineering regardless of the architectural style (EAI, microservices, SOA, accident etc) must ensure the end solution is robust and reliable. These are two key attributes of any solution and rely on handling scenarios when things do not go exactly as planned when two systems talk to each other over a network Planning for unexpected…More

Software Monoliths

Companies need to modernize software and engineering to scale to reach new customers. Many find it increasingly hard to deliver outcomes safer and faster in a rapidly changing business ecosystem because of internal complexity from existing practices, systems and integrations. One cause is “shared” collaboration of resources between teams and in this post we explore these monoliths and monolithic practices More

Messaging, Events and Data-in-Motion: Asynchronous communication patterns

When integrating systems we often end-up writing asynchronous messaging interfaces for mostly system-to-system communications. This conversation technique is great because it does not require the sender and receiver to stay connected to each other in a session at the same instance in time, it is non-blocking and often brokered (like the post office which brokers…More

Domain Service Design and Patterns

Domain services implement core logic for a business domain and are a relied upon by experience and consumer services. Domain services can be self contained and store the business logic and state or rely on an external provider system (translating from a “raw system format” to a “canonical” domain format) In this post we look…More

Salesforce Integration: Context and Patterns

Integrating with Salesforce be in a Marketing or Customer management context is the norm these days. Salesforce offers a lot of flexibility for information exchange, storage and for capturing events on change This post lists the interaction patterns we observe with Salesforce, the usage contexts, issues and best-practise Salesforce Inbound Patterns How do we create…More

How to build APIs with the right abstraction: SOAP, REST, ODATA

Leaky abstractions can be bad, especially in the context of APIs we expose to the world. Here are some thoughts on how to be less leaky and achieve more self-service with the APIs you build Modern software is built over the network with systems hooked-up either privately within the internal enterprise eco-system or with a…More

Common Service Caching Patterns

Caché implies to hide something. In a technology context this is “some service hides some data for a period of time (minutes to years)” A cache is a bit of information we stash away to better serve the clients using our service. Some of the questions cache implementers face are: Cache expiry and invalidation Mechanism…More

The difference between Open APIs and an Open API Specification

RESTful APIs can be internal (your company’s only) or public facing (Twitter). Thus internal APIs are called “Private APIs” and open to the public APIs are called “Open APIs” Now, while building an API accelerator for our clients I was asked by a well meaning colleague if this was an Open API; the intent was…More