Most of my professional career has been working in the area of commerce information systems, primarily in the “order to cash” and E-commerce space. In this time, I’ve used and heavily extended a few popular proprietary applications to conform to unyielding and particular business requirements. One could argue that purchasing a packaged product just to customize it to the nth degree is missing the point of packaged solutions. Certainly there are complexities to consider in this argument. Regardless, software exists for a reason, and that reason isn’t to stand in the way of how a business believes it should function. While I have been able to bend these popular software packages to the will of the business, doing so can be fraught with challenges, clever (i.e. unintuitive and often brittle) design, and an unusually high cost both in initial implementation and long term technical debt… the cost that keeps on costing. Along the way I’ve gotten somewhat opinionated about what I deem to be “good software”.

Early this year I found myself looking for a job because my whole team was outsourced. Dealing with the loss of a truly exceptional team, the kind you dream to working with, plus frustrations with feeling like we were forced to leave the business high and dry, I needed to find a distraction and creative outlet to feel good about. Something to do in my free time to push my design skills and grow my development skill in Scala. I wanted to develop something nontrivial and real, not just an academic project like I’ve done so many times before. Since my emotional state was partially rooted in the technical limitations of a domain I was intimately familiar with, I decided to try my hand at creating “good software” in support of E-commerce.

Of course E-commerce is a big topic, and from the start I realized there is simply too much ground for my personal project to cover in a meaningful way. There is a lot of existing software that is good at what they do, even the before mentioned packaged solutions. Re-implementing mediocre reproductions of what they deliver wouldn’t add any value, so I instead wanted to focus attention on areas I personally experienced frustrations. Plus, there is the additional challenge that my project isn’t driven with a specific business’s needs in mind. While I’ve been exposed to various different requirements from different businesses, writing opinionated business software in a generic and meaningful way requires deep and thoughtful abstractions around business process. I cannot claim to have this insight, but I can claim to have a reasonable understanding of basic business requirements and a deep understanding of technical approaches to addressing them. Since my forte is pricing, that seemed to be a natural place to focus my attention.

At first I thought implementing a pricing solution in a vacuum wouldn’t be possible. How can you price an order without knowing what a product is, let alone the context of the order? Don’t you need concrete units of measure? But then again, who is to say a different kind of pricing isn’t needed for a “sales opportunity”, lead or quote instead of an order. And what kind of units would every business use? Each? Linear feet? Kilograms? Floating vs. fixed license? In the end, the answer was not to build a system but to build a library. This way logic can be built using identity (a key can be simple or complex as long as it implements hashcode and equals), and areas of the solution that require detailed knowledge of the data model can be abstracted away, pushing ownership of this detail knowledge to code using the library. I wanted to make as few assumptions about the larger system as possible. Simply not having the larger system available to reference keeps this requirement obvious.

And so my commerce project was born. Yes the name is lame. I’m no good at coming up with that kind of thing. My own name is kind of uncommon, so it could be referred to as “matlik commerce” or “matlik pricing” in the same way people do “Joda time”? That would certainly appeal to my inner narcissist. Honestly, I don’t care what it is called if it is put to good use.

I do believe this library has a solid foundation to being a real, even “enterprise grade” (hopefully that isn’t considered a negative term), pricing solution. My goals include:

1. Eliminate common hurdles to writing correct code, such as delicate mutable state opening the system up to unintended and difficult to debug side-effects, or inconsistent enforcement of rounding rules and unsafe types (i.e. never use double for money…ever.).
2. Embrace composition of simple and reusable pricing rules to create more complex rules, possibly even through configuration.
3. Minimize implementation requirements imposed by the library, and where such requirements exist, provide clear interfaces and hooks for mapping to/from types as needed.
4. Enable full visibility into why and how a given price is determined. This information can be equally beneficial for developers, business (e.g. marketing), and customers depending on how the application uses this information.
5. Avoid design decisions that could inhibit adoption into existing JVM or microservice based solutions.

This project may grow beyond pricing at some point, such as cart management, hierarchy management, etc. I’ll likely have to build a minimal feature set for some of this to set up a pricing demo, but for now I hope to keep my attention on the pricing features. For more details, please feel free to browse the project. I need to put more effort into documentation and example code. I know that making a project accessible is key to any kind of adoption, and I’d like to see this live beyond my personal repo. As such, I’ve given it the Apache 2 license and welcome feedback.