Business Domain Driven Architecture

I wanted to write a short article on why it is so important to approach the development of an enterprise system using proper domain driven architectural principles.  The reason why is because there seems to be a lot of existing systems that have not been architected with the needs of a business in mind, or at least there has been some sort of disconnect between business needs and system development.

So many systems get built with no supporting documentation to enable adequate handover to new developer teams.  You see network administrators being lumped with development tasks that are completely out of their skill-sets because there is no resource requirements defined for such systems.

Updates for complex systems get very difficult to apply if it is not known what code dependencies exist.  Testers do not understand the system and keep telling developers that this ‘doesn’t work’ without providing a business analyst style of reference.

This situation can get very ugly as it tears at the very fabric of joint ventures and even inside organisations.  So who’s at fault for this sort of situation happening?  Is it the stakeholder’s fault for not managing their funds correctly?  Is it the developer’s fault for not approaching enterprise system design correctly?

My opinion is that is not the business or the developer’s fault as they are just doing the best they can with what they know.  Let’s look at what is really going on though to end up in this position.

Step 1. Business says, I want a system like ‘this’.  How long will it take to finish it?

Step 2. Developers say, that system will take x days/months.

Step 3. Business says OK.   Let me know when you’re done.

Step 4. Business says, are you done yet?

Step 5. Developer says,  yep all done.  Pretty cool eh!  See you later.

Step 6. Business says, Hey new developer we want this done to our system, how long will it take?

Step 7.  Developer says, well I reckon it might take y days/months but not sure about the code.

Step 8. Business says, so you done yet?

Step 9. Developer says, well I thought I would be but I don’t know about this code and is this really what you want to do to your system?

……  this is when it becomes apparent that something must have been missing in between these steps to get into this unfortunate situation.


What was missing was the developer putting on their architect hat and saying to business at step 2.. Hold On A Minute..  I’m the expert here and you need to work with me side-by-side to arrive at a plan of building your system so that we can truly align the code with your business objectives.

An analogy is if you have a really bad headache and you go to your doctor.  Do you tell your doctor that you want to have the headache fixed and this is the medication and care to use?  If you do, you might as well try and fix it yourself and save yourself the fee.  But worse, if the doctor then just says, oh ok what would you like me to do? It would be a sign of malpractice and a very shoddy treatment indeed.

So why do a great majority of developers do the same type of thing, and just accept that business knows how to architect an enterprise class system?  My view is that it is simply a lack of knowledge on the part of developers and teams leads/architects, requiring a skill set outside of coding or simply managing a team of people.

Granted, there are team leads,etc.. that do ‘confront’ business and say no, we need to use this technology, but this is just the same thing happening from the ‘technical’ side without regard to the business objectives as the driver of the system.

Technical expertise needs to be ‘combined’ with business objectives to arrive at an enterprise class system that will survive at least the first round of new developers, updates and overhauls.  There is an inherent need to create a business domain driven architecture that flows directly from business requirements to code fragments.  A wholistic perspective is required to transfer use-cases to test-cases, even before code is written.  I’m definitely a fan of agile style development but this does not mean flying by the seat of your pants and producing throwaway code, just because it is the first iteration.

So my point is this.  If you are a developer/architect/team lead/tech person then understand that a process is required to align business requirements first in an architectural sense before you begin coding or setting up Microsoft Project.  If you are on the business side, then consult with your technical experts on your objectives and then get the most benefit you can before ordering yourself a system.

A side-by-side methodology gives businesses much more valuable systems for the same price.  If you are working with a business domain driven architect you can achieve a much better ROI than the traditional top-down management approach.

Enhanced by Zemanta

About the Author John

Leave a Comment:

Mike says February 1, 2013

Hi, will this work without having a regular website?

John says February 1, 2013

@Mike – the business domain driven architecture methodology tends to work with any type of technical application project.

The key to implementing I’ve found is to directly link up business requirements with the actual business domain code in the application.
This tends to involve UML ‘use-case’ style diagrams and code generation frameworks.

Add Your Reply