I read some books about software architecture as we are using it in our project but I can't classify the architecture properly. It's some kind of Enterprise Architecture, but what exactly... SOA, ESB (Enterprise Service Bus), Message Bus, Event Driven SOA, there are so many terms in Enterprise software....

The system is based on custom XML messages exchanges between services. (it's not SOAP, nor any other XML based standard, just plain XML). These messages represent notifications (state changes) that are applied to the Domain model, (it's not like CRUD when you serialize the whole domain object, and pass it to service for persistence). The system is centralized, and system participants use different programming languages and frameworks (c++, c#, java). Also, messages are not processed at the moment they are received as they are stored first and the treatment begins on demand.

It's called SOA+EDA -:)

  • Possibly event sourcing? Oct 26, 2011 at 17:35
  • @Matthew Rodatus, looks like no, we do not capture application state, we capture domain model state changes. It's lik CRUD when you update your whole object in DB but, also we capture state changes like Order #123 status changed to shipped and pass this notification using XML message to system participants. Oct 26, 2011 at 17:40
  • That sure sounds like event sourcing to me. Did you read some of the article? In the article, application state means (perhaps among other things) domain model state. Toward the beginning of the article, Martin says "The key to Event Sourcing is that we guarantee that all changes to the domain objects are initiated by the event objects." Oct 26, 2011 at 17:51
  • Big Ball of Mud comes immediately to mind ?
    – user7519
    Oct 26, 2011 at 21:29
  • @JarrodRoberson I don't think so. Clearly it's not masterpiece of software architecture, but lots of good programmers and architects worked on this system. When good programmers code something, even when they don't follow specific design pattern or architecture, they end up with one, but not 100% perfect. Thats why I'm trying to identify the closes architecture and make code better. Oct 27, 2011 at 4:33

2 Answers 2


That sounds like Event Sourcing, which "Capture[s] all changes to an application state as a sequence of events" coupled with a Message Bus, which solves the problem of "several existing systems that must be able to share data and operate in a unified manner in response to a set of common business requests."

On event sourcing:

The key to Event Sourcing is that we guarantee that all changes to the domain objects are initiated by the event objects.

In the article, the use of the term "application state" appears to mean "the state of the domain model."

On message bus:

A Message Bus is a combination of a common data model, a common command set, and a messaging infrastructure to allow different systems to communicate through a shared set of interfaces.

I don't think the ESB pattern is being used, since it:

  • transforms messages depending on the client and
  • has mutually interacting clients

From what you've said, your clients all process the same message type and they are not peers but have the event change notifications published to them by the centralized server.

  • Matthew Rodatus I have read half of article it's close, but I still think it's not what we have, with Event Sourcing, your model state is composed of series of events it's scattered between captured events, we have an actual version of object stored in database, plus events, but the key point here is that we do not simply capture and store them in local database but we need to send them to other system participants. So yes we use Event Sourcing locally, but this patern\design doesn't cover message exchange. Oct 26, 2011 at 18:16
  • Matthew Rodatus I'm more interesed in how to classify our message exchnage architecture. I'm reading wikipedia about MOM, ESB, EMS and they all apply to my case, but I don't see key difference in this architectures, and what roles they have. Oct 26, 2011 at 18:24
  • @Alex So, your system receives change events and forwards them to other systems in addition to applying the change events to the static domain model in the database? Am I understanding right? Oct 26, 2011 at 18:47
  • Well yes, you can think of it (system) from this point of view. Oct 26, 2011 at 19:46
  • I'm not an expert in EAA, but it sounds like you have two main design patterns in play. It's a plain message bus where the messages are change events serialized in XML. I don't think ESB applies here, since there is no translation of messages into different formats. It sounds like you forward on the message in its XML format as-is, regardless of the type of client. It also doesn't sound like you have "mutually interacting apps" (wikipedia on ESB). Oct 26, 2011 at 20:10

It sounds like some form of a context aware broker architecture. Found two research papers(pdf) referencing these as a COBRA architecture.



Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.