When you tell your infrastructure what you’re trying to do, it can help you do it better. [I've] used the word “model,” which might sound frightening and esoteric. But everyone does this anyway! They just don’t call it that. When people design a system in a message-centric way, they write long documents (aka “models”) describing who has to send messages to whom, in what format, at what times. Then they email these documents to each other and implement the various components based on what the documents say. In the process, they write a lot of code to encode and decode data, validate it, monitor and respond to the system’s status, manage application state, and so on. And once they’ve done all of this work, they plug their components in and find out whether the documents had any ambiguities in them and whether everyone has correctly implemented all of those infrastructure pieces I enumerated.
The truth is, from the point of view of the real business logic, “the middleware” isn’t just a messaging or data-distribution component purchased off the shelf. It also includes all of the stuff your in-house infrastructure developers had to build on top of that to make the applications work right.Read the rest here.
This post is a follow-up to a previous post, aka Part 1.
No comments:
Post a Comment