BIAN Applied to Microservices: Mapping to Domain-Driven Design
Many financial institutions are adopting microservices in developing new applications as well as modernizing existing applications. Central to the design of microservices is the partitioning of a large application into a suite of small services, each with clear business capabilities and a defined boundary, running independently and communicating with each other using lightweight protocols such as RESTful APIs and events. Domain-Driven Design, with a set of concepts and patterns for designing and developing a domain model, has been made popular by the increasing adoption of microservices architecture in the industry.
Banking Industry Architecture Network (BIAN) defines a component business blueprint for the banking industry. BIAN started with specifying a set of Service Domains, each as a discrete, non-overlapping, and elemental business capability, responsible for handling the full lifecycle of its business function. The Service Domains are organized into groups and cataloged in a reference framework called the Service Landscape. BIAN has traditionally been used as a component business architecture for enterprise analysis and applications at a high level. In recent years, BIAN has extended the Service Domain specifications to provide semantic models for describing the business information governed by a Service Domain, and for defining the service operations as the underlying exchanges between the Service Domains. These recent extensions pave the way for leveraging BIAN reference models in the design and development of applications based on microservices architecture.
Based on my experience of supporting several financial institutions in adopting BIAN in their digital transformation programs, I would like to share an approach to applying BIAN to microservices based applications. In this article, I will establish the mapping between the concepts and models in BIAN and those in the Domain-Driven Design, and illustrate that BIAN provides an industry specific framework for applying Domain-Driven Design. This mapping is to lower the learning curve and to promote a more consistent adoption of BIAN for the practitioners who are familiar with Domain-Driven Design or BIAN. In a future article, I will show the implementation of a microservice for customer financial position where account information is augmented to support new business requirements, using BIAN models and a DevOps tool supporting Domain-Driven Design.
Domain Driven Design (DDD) Revisited
Domain-Driven Design is an approach to software development that centers on programming a domain model that has a rich understanding of the processes and rules of a domain. The approach, which is particularly suited to complex domains where disorganized logic needs to be organized, can be described through a catalog of concepts and patterns (for details see [1] and [2] in References):
Domain and Subdomain A Domain represents what a business does, including all of the knowledge involving the business and how the business operates. It also represents the problems the business faces that you are trying to solve. A Subdomain is a sub-part of the overall business domain, representing a single and logical domain model which breaks up your whole business domain.
Bounded Context Bounded Context is a semantic contextual boundary; in it, each component has a specific meaning and performs certain tasks. DDD deals with large models by dividing them into different interconnected bounded contexts. Bounded Context is a central pattern in DDD’s strategic design that deals with large models and teams. The integration between Bounded Contexts is known as Context Mapping. There are different styles of integration (such as RPC, RESTful HTTP, and messaging), and various kinds of Context Mapping relationships (such as Partnership, Customer-Supplier, and Anticorruption Layer).
Ubiquitous Language Ubiquitous Language is a common language that is developed by the team to create the software model that functions with the Bounded Context. It is used among team members and users. The Ubiquitous Language is rigorous, ideally based on the domain model used in the software.
Entity, Value Object, Aggregate, Service, Service Object, and Domain Event An Entity is an object with a distinct identity that runs through time and different representations. It is also known as a reference object. A Value Object is an object that matters only as the combination of its attributes. Two value objects with the same values for all their attributes are considered equal. An Aggregate is a cluster of entities and value objects that can be treated as a single unit. An aggregate has one aggregate root. References from outside the aggregate should only go to the aggregate root. Aggregates are the basic element of transfer of data storage. Each aggregate forms a transactional consistency boundary. This means that within a single aggregate, all composed parts must be consistent when the controlling transaction is committed to the data storage, according to business rules. A Service is a standalone operation within the context of your domain. A Service Object collects one or more Services into an object. A Domain Event is a record of some business-significant occurrence in a bounded context.
Banking Industry Architecture Network (BIAN) Distilled
BIAN is an association of banks and solution providers with a shared vision of defining a component business blueprint for the banking industry. The figure below shows the BIAN reference model, including the Service Landscape (left side) and Service Domain specification (right side). More details about BIAN can be found in the practitioner’s guide ([3] in References).
Service Domain Service Domain is the foundational building block of the BIAN model to represent the business functional components. A Service Domain is defined to be responsible for implementing one pattern of behavior to instances of one type of business asset (asset type). The asset is what the business possesses, including tangible things such as buildings and computers, or intangible things such as relationships and knowledge. The pattern of behavior, representing the way an asset is controlled or leveraged, is called a functional pattern. A Service Domain has the following architectural properties:
- A discrete, non-overlapping, and elemental business capability, responsible for handling the full lifecycle of its business function. As a result, a Service Domain encapsulates its business information and logic, combining people, processes, and systems. BIAN adopts a completely different view of business activity compared to the more conventional process centric approaches.
- Stable over time, supporting incremental development and adoption. It has a business role or purpose that is defined independently of the way it might be implemented. As business practices and techniques evolve, the inner working of a Service Domain may be enhanced with additional features.
- Canonical, or the ‘same for everyone’, supporting high levels of interoperability. It defines the generic functional building blocks that make up any bank. Its role/purpose can be consistently interpreted from one deployment to another. This means a bank or solution provider can switch out the underlying system for a Service Domain and replace it with an alternative solution.
BIAN members have spent several years defining a comprehensive collection of the Service Domains that cover most banking activities.
Service Landscape The Service Landscape organizes all the Service Domains into groups based on large business areas and more narrowly defined business domains within these areas. The layout is simply intended to help with the identification and selection of Service Domains.
In recent years, BIAN has extended the Service Domain specifications to include Control Records, Behavior Qualifiers, Information Profile and Business Object Model, and Service Operations.
Control Record The Control Record is defined as the combination of the asset type and the generic artifact that characterizes the functional pattern of the Service Domain. The Control Record is comprised of all the business information governed by the Service Domain as it completes a full cycle of its work. For example, for Current Account Service Domain, the asset type is Current Account, and the generic artifact for Fulfill functional pattern is Arrangement; therefore, the Control Record is Current Account Arrangement.
Behavior Qualifier A further level of breakdown for the Control Record is often required to define a sufficiently narrow business context. The Behavior Qualifier is introduced to characterize the finer grained activity that is a part of the overall work done by a functional pattern. The Behavior Qualifier retains the core behavioral characteristics of its associated functional pattern. For example, for Current Account Service Domain, Behavior Qualifiers such as Direct Debit, Deposits, Withdrawals, and Payments are used to describe the specific features of the Service Domain characterized by the Fulfill functional pattern. Additional levels of breakdown can be applied consistently as needed.
Information Profile and Business Object Model In addition to the Control Record instances (and the contained Behavior Qualifier instances), Information Profile contains information used in the control and management of the Service Domain as a service center and the analysis and reporting of usage and performance of the Control Record instances the Service Domain manages. Using the modeling approach for Information Profile, the recent BIAN Business Object Model (BOM) provides a more precise conceptual basis to describe the business semantics and data of BIAN Service Domains. The BOM contains models for a growing number of Service Domains, Control Records, and mappings to ISO20022 business components and elements.
Service Operation and Service Group A Service Domain offers a collection of service operations and usually consumes the service operations of other Service Domains as needed to complete its work. BIAN defines the Service Operation to indicate a service dependency between Service Domains. BIAN defines a general set of action terms that characterize the purpose of an offered service. These action terms can be grouped into categories. A Service Operation specification is defined using the applicable action term and optionally a behavior qualifier, with payload specified as an organized list of semantic attributes (as BOMs) covering the key business information provided and returned for the service exchange. The Service Operations are grouped into Service Groups based on the categories of the action terms.
Mapping Between BIAN and DDD
The BIAN approach to specifying Service Domains using the asset-leverage model (one asset type + one functional pattern) provides a unique domain decomposition model for the banking business domain. The BIAN reference model also provides a ubiquitous language for both business and technical practitioners in describing and modeling business capabilities. BIAN concepts and models, such as Control Record, Behavior Qualifier, and BOM, can be used to construct DDD domain models such as Entity and Aggregate. The figure below shows the mapping between BIAN and DDD.
BIAN deals with the DDD Domain and Subdomains for overall banking business As a conceptual business component framework for banking, BIAN decomposes the overall banking business Domain into a set of Subdomains called BIAN Service Domains. The BIAN Service Landscape organizes all the BIAN Service Domains into larger Business Areas and smaller Business Domains, which are Subdomains themselves. The BIAN Service Landscape and Service Domains provide a generic reference framework from which a component design blueprint for a particular bank can be derived.
BIAN Service Domains map to DDD Bounded Contexts Each BIAN Service Domain, as a functional building block, defines a Bounded Context, a contextual boundary in which an asset is leveraged in a specific way. The BIAN asset-leverage model provides a unique and consistent way of dividing the large and complex banking Domain into a set of discrete, non-overlapping, interconnected Bounded Contexts.
BIAN provides a Ubiquitous Language BIAN also provides a common language to describe business capabilities, what a bank does, what it needs to know, and what services are offered and required. It is developed by the member banks and has been increasingly adopted by the banks and software providers. The common language is rigorous and has been incorporated into the business architecture and point solutions by banks and solution providers. The common language increases the interoperability in one project or between projects within a bank, between banks and solution providers.
BIAN Control Records and Behavior Qualifiers map to DDD Aggregates BIAN Control Record consists of the business information for completing a full cycle of its work. BIAN Behavior Qualifier is a breakdown of the Control Record to define narrower business contexts and more specific purposes for the service operation. All composed parts of a Control Record or Behavior Qualifier must be consistent when the controlling transaction is committed. BIAN Control Records and Behavior Qualifiers map to DDD Aggregates. BIAN BOMs, which are used to model Control Record, Behavior Qualifier and payload of Service Operation, map to DDD Domain Objects (Aggregate, Entity and Value Object).
BIAN Service Operations and Service Groups map to DDD Services and Service Objects A BIAN Service Domain offers a collection of Service Operations that are consumed by other Service Domains to complete their work. BIAN Service Operations map to DDD Services while the Service Groups maps to the DDD Service Objects.
BIAN Events map to DDD Domain Events BIAN has focused on defining Service Operations, which are used in conventional orchestration that coordinates service calls between Service Domains. To support event-based exchange, BIAN is currently extending the Service Domain specifications to include the Events produced and consumed by the Service Domains. These Events map to DDD Domain Events.
Summary
In this article, I demonstrated that BIAN can be used as a framework for the Domain-Driven Design approach by establishing the relationship between BIAN concepts and models and the corresponding ones in the Domain-Driven Design. BIAN can be used at a strategic design level by providing a unique and consistent way of decomposing the banking business domain into a set of Bounded Contexts. It can also be used at a tactic level where the information models are used as the starting point for designing and constructing domain objects such as Aggregates and Entities.
References
[1] Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, 2003
[2] Vernon Vaughn, Domain-Driven Design Distilled, 2016
[3] Guy Rackham, BIAN Semantic API Practitioner’s Guide V8.1, 2020
