There is a trading system. Handling all of the complexities related to offers acceptance, negotiations and final approval. A new requirement jumps in. You now have to report on daily basis all the finalised trades to the 3rd party organisation according to the latest regulations in your country. Additionally, some of the suppliers (“customers” in the trading system) may benefit from these reports. In this case however, it will be them who ask for data.
Now the enterprise world opens up. The core of the trading system has already covered lots of requirements. It already exposes all the necessary data. There is an XML for this. And even XSD. It just happens to be in a format different from the one required by the 3rd party organisation. And yes, you guessed correctly – suppliers are not interested in this format neither. Oh, I would forget, it’s 20GB of XML data sent each night.
So what do you do? You extend the existing system of course. Add a class here and there. Find a cron task – oh, right, it was intended to send night printouts batch to the corporate printer, but with a little tweak or maybe two it will also send these trades out, right? No big deal.
Or maybe you create a separate service to handle this communication. With its own model. And maybe its own UI, even if this is only an admin console. You can place the SAX parser here to translate XML messages exposed by the trading system into the external ones, appropriate for the 3rd party organisation (please, do not even start with DOM parser for 20GB of XML unless you want your servers to explode).
Look how nicely this decouples new requirements from the current system. They really do not have to belong to the core of the trading platform. Look how nicely this resonates with the latest trend to microservice everything. Oh, by the way. I haven’t heard a microservice used as a verb yet. But if agile, being an adjective, might be used by the whole industry as a noun (I highly recommend you this Agile Is Dead talk by Dave Thomas, GOTO conference 2015), maybe microservice can be used as a verb?
Back to the topic. What about introducing a new database for the new service? Don’t panic, you don’t have to install a whole new Oracle instance. It might be just a separate schema. Any mechanism available in your DBMS to logically separate structures for the new service will do. No more hidden coupling on the database level. This is a completely separate database accessible only from within the new service. Maybe you have always wanted to try one of the Document Databases out? No problem. Go for it, it’s your small playground anyway. Even if your decision was wrong, the cost of changing the solution will not hurt.
Of course the new service requires more than just messages sent over by the trading system. What about specific settings required to handle communication with each supplier? Add it to the new service. You will avoid polluting the trading system with all these technical details. You need a new GUI for this? Add GUI. At least these settings will be kept close to their usage. Within the bounded context of exposing finalised trades to external systems.
You need more data in the new service. Your Product Owner comes to you and says, you also need to read postal address of the supplier from the core system. Yes, this looks harmless at first. This is the only information missing in data exposed by the trading system – you hear. Somehow feeling that there is more to come. You know that next week this will be a balance of the previous month. There will be no end to such requirements. You will wind up flooding the trading system with requests to fill in gaps, prior to actually sending any data out. So do not do directly what they say. Find the real source of truth for each piece of data needed, the right system. Maybe you will need something from the trading system, maybe from CRM. Each time required data is changed, publish a domain event. And store it inside the new service. You will not have to actually ask for it when some supplier sends you a request for data. You will already have it. The temporal coupling between the new service and other systems around will be removed. The trading system might be turned off, CRM might be turned off (let’s say they are under maintenance), and the new service will still work just fine.
Is this data duplication? Yes, partially. That’s why you really need to know what the source of truth is. And always get data from the right place. Deny to forward data which is just a derivative.
You say it’s too much work? Too much overlap with the corporate framework in the core system. That it already does the cron stuff. And data access. Unfortunately I can’t fully address this question in the scope of this post. We will get to this one day. The short answer is: forget about it. It’s not worth it. You do not need a framework. Choose the right tool. Making a scheduled task in Java EE is a single annotation. Making it configurable is not much more. You do not need a framework to do this. Neither for data access. And your UI? At least you now have a chance to try something more lightweight. Maybe these old JSF components weren’t that good after all?
Each requirement sounds quite simple at first. But remember. It will grow. So do not hesitate. Once you find a new requirement for a separate area, a separate bounded context, celebrate it. Don’t let the Big Ball of Mud grow on you. Make a new service. Yes, I know this is a more complex approach at first. So start with something small. Learn. Read and watch how others do this. Look for Udi Dahan, Greg Young, Fred George and others. It may seem complex at first. But the professional, decoupled and maintainable solution will make this effort pay off.
