Domain-Controlled Architecture

By Sean

Software architecture tends to lean heavily a model-view variant that often doesn't scale, is overcomplicated in implementation, and can be difficult to test, maintain, or port to other platforms/infrastructure. Domain-Controlled Architechture is our way of applying software design fundamentals, simplifying and flattening architecture, and reducing cognitive load, resulting in better, easier to maintain designs that are a pleasure to work on.

If you asked me to sum Domain-Controlled Architecture (DCA) up in one word, it would be Elegant. On it's own, it might not seem like much, might not seem particularly groundbreaking, and might even seem to be a little old school. DCA wasn't created to impress anyone. It's a tool in our kit that helps us to navigate the realities of the modern tehnology landscape, where there is an overabundance of complexity in terms of boilerplate code, code generation hell, and endless examples of untestable, unmaintainable, and unstable software. DCA is so simplified that I imagine many people will assume it is lacking, can't work in today's complex world, and that it won't be worth your consideration. Having conceptualised the pattern, and worked with it for quite some time now, I am in some ways both DCA's and my own worst critic, yet I would also put this simple design up against any other architectural model any day, and if someone told me that my life would depend on the architecture I chose, I would choose DCA every single time. Not because I defined it, but because it never let's me down. It has fulfilled every expectation, and even been adapted to systems adn configurations that I had never originally intended it for.

I am not going to call DCA a silver bullet solution. No design truly is, and every architecture has it's benefits and it's applications. However, if any design could be said to come close to being a one size fits all solution, DCA would be a top candidate. There is one very good and simple reason for this. DCA adheres to sound software engineering principles, and encourages the developer to do the same. It strips away all of the unnecessary ceremonial elements of modern architectures, relies on minimal pattern concepts that are themselves greatly simplified, and defines a strict set of rules to keep your efforts focused and in line with the ideals of the architecture. It ensures your software is built such that it is deterministic, easy to test, easier to mock the really hard to test stuff, and makes sure that you can effortlessly (by comparison) get 100% test coverage for all of your program logic. I've had code coverage tools tell me that my unit testing covers 95% of the code, with only the peripheral and swappable elements left untested; In other words, only the superficially thin layers that hook up other peoples code requires checks and tests outside of my test automation.