Scott M. Felder

Big Ball of Mud

Let’s start with my original example business, Acme Enterprise.  Acme wishes to build an ecommerce system to sell its products to its customers.  The developers at Acme start out by building a web application that customers can come to for placing orders, employees in the pricing department can update product prices, and employees in the inventory management department can maintain product SKUs and product levels.  As time goes on the pricing department wants to add new functionality to the system to maintain promotional pricing on products, discount pricing on products, etc.  The inventory department wants to add new functionality to the system to provide auto-replenishment on products, warehouse location of products, etc.  As the application grows into one monolithic system it can quickly become unmanageable in its current form, or as some call it, BBOM – Big Ball of Mud.  More importantly, the different departments within Acme define the term “Product” differently.  The sales department defines a “Product” as an item ordered by a customer and added to a shopping cart with a price and quantity ordered information attached to it.  The pricing department defines the “product” in terms of not only unit price, but promotional pricing, and marketing campaign pricing that is valid for a particular time period. Meanwhile the folks in inventory management define a “Product” in terms of Quantity on Hand, Warehouse Location, and Reorder Threshold Trigger.  As the system grows, so does the complexity and the size of our BBOM.

Bounded Contexts

This is where Domain Driven Design (DDD) can help with the design of our ecommerce system.  When we start to define the term “Product” with the people responsible for products in each of the departments within the company, we realize that they all care about this thing called a “Product” but they each talk about it in a different context.  This is where DDD introduces the idea of a Bounded Context.  Our system can be split into separate contexts each with its own explicit boundary.  So what we end up with in our system is a bunch of Bounded Contexts for each of the different contexts within the system: an inventory context, a pricing context, sales context, etc.  Each Bounded Context has its own model and ubiquitous language that defines the domain and entities like “Product” uniquely to its own definition.  The key phrase to our bounded context here is “explicit boundary”.  Each context provides a contract to the outside world to interact with and can be viewed as its own application within an application.  This can provide modularity to our overall system design.  One Bounded Context shares data with another Bounded Context via a Context Map.  A Context Map exposes a well defined contract interface that can be consumed.

Bounded Context as a Service

Now let’s take our DDD ecommerce system and apply SOA principles to it. Remember when I stated that a Bounded Context provides an explicit boundary?  One of the core tenets of SOA states that “Boundaries are explicit”.  I also stated that a Bounded Context can provide modularity within our system and that a context can be viewed as an application within an application.  Well another core tenet of SOA states that “Services are autonomous.” Hmm, so what else do bounded contexts and SOAs share in common?  A Bounded Context within our system communicates with another Bounded Context within our system via a context map that provides a contract interface to the outside world.  SOA; “Services share Schema and Contract, not Class”.  So when we compare the Bounded Context of our DDD and the Services of our SOA, there really isn’t a whole lot of difference between the two.  Maybe in an SOA we should call them “Bounded Services”?  SOA is about the separation of Bounded Contexts in our application into their own services so looser coupling can be achieved while providing a certain degree of service reuse within our enterprise.  Our context map or interface to the SOA service can be done via a web service, restful service, or WCF.  For example, in our DDD ecommerce application, if we wanted to replace the inventory context with a third party inventory management or ERP system like SAP, there may be a bit more work involved to decouple it from the old system and integrate the new SAP system.  With SOA, we have a lesser degree of coupling to deal with so integrating to the new inventory system will be easier.  Notice, I said “easier” not seamless.

EDA with NServiceBus

This brings me to Event-Driven Architecture (EDA), more specifically, EDA with NServiceBus.  As we’ve taken our initial BBOM ecommerce application and we introduced DDD principles to it and refactored our system, we began to decouple the system into different functional modules, or Bounded Context, within one application running on our web server.  Each department (inventory, pricing, sales), would access the same system to update their various domains of information.  As we moved to SOA, we took this one step farther by making these contexts autonomous services that can be distributed on different servers running within our enterprise, providing user access to a particular service to only the people in the department that need to update data within that service.  The problem with traditional SOA is it still gives us a certain level of coupling with our enterprise applications between services.  If the inventory service needs to inform the pricing service that a new SKU has been entered into the system, the inventory service must know that the pricing service exists within our enterprise.  Meaning, the inventory service must be programmed to make a service call to a service interface (web service, WCF, socket call, etc.) on the pricing service.  If we decide to use a different system in the future to do pricing, we need to update the inventory service to call the new service interfaces on the new pricing system.  This is where event messages and NServiceBus can help.  If we define a series of business events that describe important transactions within our enterprise, we can publish their event messages to a message bus.  Now instead of our services interacting directly and having to be aware of one another in the enterprise, each service only needs to know to publish event messages to the message bus, and only subscribe to event messages on the message bus that it cares about.  So in the case of our inventory service, and our pricing service, the inventory service can publish“New SKU” events and the pricing service and subscribe to “New SKU” events.  At no point does the inventory service need to know about the pricing service and conversely, the pricing service doesn’t need to know about the inventory service; now what “links” the two systems together are the “New SKU” events, and more importantly the data contained within.  In essence, the event messages and the service bus, in this case NServiceBus (but we could use others) become the “Context Map” defined back in our DDD application.  The event messages are our contracts and NServiceBus becomes our service transport layer to communicate between Bounded Contexts/Services with a higher level of decoupling between our services than we had with our traditional SOA.

In conclusion

            NServiceBus provides an easy to use API to the framework to work with so we can create an event message driven architecture.  Publishing event messages via NServiceBus will allow for a much more loose coupling design between the different Bounded Contexts or Services running in our enterprise.  While applications or services will always have a higher degree of coupling between their application layers, (UI, Business Layer, DAL, etc.), Event-Driven Architecture with NServiceBus can provide for a much lesser degree of coupling between the explicit boundaries of the services.