In the foreword of Evans' book, Martin Fowler stated:
There are many things that make software development complex. But the heart of this complexity is the essential intricacy of the problem domain itself. If you’re trying to add automation to complicated human enterprise, than your software cannot dodge this complexity — all it can do is control it. | ||
| -- Martin Fowler Domain Driven Design by Eric Evans (2003) | ||
These words grasp the simple rationale for Epic.
When we face a complex enterprise business, we should rapidly realize that everything we know about software architectures, development techniques, large scale integration and so, is just a detail.
Our customer will pay us to solve his own problems.
He don’t want to know about agility, software integration, CAP theorems, cloud computing, data security or computational complexity: these are technicalities that he would avoid at all. These are our problems!
Enterprise customers pay us to get a competitive advantage by solving well known problems of their own. They don’t want new, unknown, problems to pay us for!
Nevertheless, even as "hands on" modelers, we often undervalue their "human" problems. Whenever we adapt the models of our customer’s problem domain to our existing frameworks, we are mixing two order of complexities: business rules and technological constraints.
"I don’t fight my framework!" you would say. Evans explicitly wrote that we should not. Actually, most of the times it is the wisest choice.
But what if you had a framework that hasn’t to be fought? What if you could easily adapt any infrastructure to clean models that capture the business processes only?
What if we could simply code nothing but business?
In 2004 the European Union issued the Markets in Financial Instruments Directive (also known as MiFID). The main objectives of the directive were to increase competition and consumer protection in investment services. Suddenly many big banks all over the europe begun to adapt their advisory softwares. Many software companies (and consulting firms) clashed with a complex legislation to rule existing business processes, in an heterogeneous set of technological environments.
Four years later the European Union amended the directive, already adopted by many states, variously changing the rules.
We soon realized that it was a strategic point to keep the domain fully indipendent from the infrastructural choises that each bank would had taken. Moreover the problem was too complex to take technological compromises. We had to protect the model as the most important asset in our stack. We had to base our entire stack on the domain model itself, adapting everything else.
But unfortunately, Epic did not exist.
After a long climb towards trials, failures and insights, we realized a set of modeling patterns and practices that works very well together against complex domains.
We took so much confidence in such patterns, that when we now see problems in their adoption, we often start a new whirpool to get a deeper insight of the context. Such process often shows a misunderstanding in the domain language.
At the core, Epic is a coherent set of modeling patterns, best practices and lessons learned (with a lots of anti-patterns to avoid: did you know that lazy loading and event brokers are among our new singletons?).
As you will see, some of the patterns we propose are really challenging from a technological point of view.
If not taken together as a whole, they could seem impossible to implement. Actually, they are impossible to implement (correctly) if mixed with those we propose as anti-patterns. We learned this the hard way.
So what?
Well, Epic is more than a set of coherent patterns: we designed a framework and a set of tools to inject the infrastructure into the domain model itself, without any need to adapt it.
Epic will help you to
- reduce the effort to code and maintain the model implementation
- enforce the aderence to patterns (if you want to)
- adapt the infrastructure you need to the model itself (persistence, caching and so on will be orthogonal to the modeling code)
- build complex, beautiful and highly interactive user-interfaces
- follow a simple, predictable and traceable development process, that could become very fast, thanks to its parallelization’s capabilities
- minimize the effects of infrastructural changes on the application reliability
Epic will never help you to cut modeling hours. On the contrary, you should invest a lot on them! Whenever you have any doubt about the business, stop coding, kidnap the domain expert and start a new exploration whirpool.
Moreover, it require high skills in object oriented design. Such skills are rather expensive to acquire and thus building a productive team using Epic will require budget. As a conseguence Epic will minimize the development efforts and maximize the software quality (cutting maintenance’s costs), but will not reduce the budgets required.
Keep this in mind: Epic could overwhelm simple projects!
Avoid Epic (and domain driven design) when you do not have complex business rules and do not require high reliability while sticking to such rules.
This manual is targeted to people involved in the entire lifecycle of enterprise applications with custom development. An obvious prerequisite is a good experience in software development and object oriented design. Furthermore a good understanding of the Evans book is mandatory.
Here software architects and software developers could learn when to adopt the Epic framework, and how to adapt it to their architecture and development processes.
Project managers could use the manual to grasp the development process emerging from a domain driven team using Epic. In particular, they will appreciate the concreteness that Epic imposes to the development process, always looking for a better understanding of the customers' processes.
Modelers and developers will gain a set of powerful tools, that will increase their ability to cut complexity into indipendent axes, allowing an easy parallelization of development efforts.
The first part of the manual introduce patterns and practices that come from real-life challenges encountered by a team of developers building corporate applications. Such patterns will constrain (and thus will ease) the design, the development and the evolution of the domain model itself. As such it is mostly written for "hands on" modelers and architects.
The second part document the various components of the Epic framework. It’s designed for the full development team (from DBA to GUI designers).
Finally, the third part will target architects, team leaders and project managers, describing the process' changes that could be required by the adoption of Epic.