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 Microservice and Integration Enterprise Architects
Enterprise Architecture (EA) is starting to feel a bit stale While I love the structure TOGAF ADM provides and the associated standard industry reference models for Capabilities models etc. but recent (3-4 years) experience with this practice has been disappointing The problem 1. Growing disconnect between solution and enterprise architecture teams and models My main…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
Engineering Reliable and Robust Integration Solutions through better Error Handling
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
Recognising Software Monoliths: 7 key types
A monolith in software architecture a term used to describe some service that is large, complex and shared across different business functionalities. Changing any aspect of this can be daunting not just from an engineering standpoint but from a testing, delivery and release standpoint as well As teams look to decompose monolithic software into domain…More
Capturing the essence of your software with diagrams: Techniques for the engineer, designer and architect
Pictures are “worth a a thousand words” and in the software industry they can save time and help inspire the collective imagination A good picture about a software system at right level can convey the right details. It is about what you leave out as much as what you put in and structure – there…More
3 Key Asynchronous Communication Patterns: Ways to talk offline
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, is non-blocking and you can make it reliable through message persistence, incremental…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
Building strategic public and partner API experience: The power of experience adapter and an abstraction layer
As organisations look to take their offerings to the world outside for specific customers, partners or general public and grow their business, they must balance the risk of opening the door to internal mission-critical systems vs value provided. These offerings also must deliver the right experience, requiring an abstraction over the internal organisation services to…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: Lessons in being less leaky
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
