This experience report explores three different MicroProcess architectures and the situations in which each was applied. We start with a traditional, Design Pattern-based approach which still efficiently handles customizations without resorting to complex message-passing designs. Then we follow up with a different architecture appropriate when many tasks must be done, but the order is not too important (with examples). Finally, we discuss the uber-popular MicroService architecture, but with a focus on solving the “fuzzy” problems that lack definitive answers (fraud detection, loan risk, etc.) Each of these has base code in the public domain! If your environment requires constant tweaking for individual clients, you don’t want to miss this talk!

MicroProcess refers to a family of architectures which share some key traits:

• Low coupling of components
• Ease of introduction of changes
• Simple management of variations

The first architecture is rooted in Design Patterns (GoF book). Working through several patterns, we build a traditional architecture that retains flexibility. We include several recent applications of this process as well:

• Command pattern: The base pattern captures individual tasks, as well as their reversal
• Composite pattern: We glue these individual tasks into groups
• State pattern: Handle the restoration of suspended processes
• Visitor pattern: Extract the state of a process, necessary for resuming a process

The second architecture is an evolution of MicroServices, without having to invest in complex cloud configuration issues. In this architecture, a Step captures the individual tasks, and Status captures the current state. The Steps are executed (in any order!) until a steady state occurs (Status is not changed). The Status then reflects:

• Successfully results
• Negative results (aka Errors, which need correction)
• Pending results, and the responsible party

Through the Status, a UI can be built to resolve pending issues and errors.The final architecture inspired the original term MicroServices. In this architecture, an event bus is used to isolate the tasks from each other, and to restrict coupling to only the message format (JSON in this case). This architecture addresses problems without clear-cut answers (“fuzzy” problems in my world) like fraud detection, decisions to lend money, finding the best advertising copy. It also supports implementation of the various tasks in the appropriate language. The use of this architecture in several projects will be discussed.