Domain Based Development versus Dynamic Applications
Thinking about domain based development versus dynamic applications.
What is Domain based development?
We can think of domain based development as being an application which has code clearly matching domain based requirements. Or in simple terms, an application which is tightly coupled to the customers' requirements.
For the purpose of this document, we've decided to call this domain based development rather than "Domain Driven Design", Because we want to make her clear distinction between domain based development and dynamic development.
An example could be a particular enterprise which sells books. This application would have multiple layers of logic within it it is likely that if this company had multiple sites and offices, we may see these offices names within the domain. Of course we could have a more generic approach and have an entity called "office", for example another entity called "location". However, it is not unacceptable to have domain specific logic by an entity that doesn't necessarily correlate to another entity's logic. These types of applications end up with significant amounts of code. As the business grows, so too does the code base. Even where the code base is well maintained and of high standard, the amount of code can become overwhelming. One of the advantages to this type of approach developing applications is that the actual business requirements will get served quicker.
Imagine, for example, you are starting with a blank project and you have some requirements to buy and sell products on Amazon. Potentially you have an EPOS system, and a website with domain specific content within it. We can focus on Coupling the solution to the main base specific logic and potentially have some services which are more abstract in terms of integrating with Amazon. We may decide to specifically place our Amazon based logic within a folder called Amazon. Of course we can see the issue here. Imagine, although it seems highly unlikely that Amazon no longer existed. We would need to remove this from our codebase and replace this with a different provider potentially.
In this short discussion on domain based development, we can already start to draw up costs and benefits to Domain Based development.
One clear challenge to working in enterprises is how to name objects and resources. One challenge we have seen repeatedly in larger financial institutions is where domains are coupled to applications. The classic example is to name a folder after an application. In reality, the data that the application produces is agnostic to the application. Naming that folder after the application means that if the application gets replaced with another one, there are all manner of services and interfaces which will need replacing. This can become what is known as a transformation project and transformation projects can can take years to implement in larger organisations.
Sometimes these organisations do see the benefit in naming resources by application name. Staff can find it easier when referring to resources by application name. One way to get around this is to use contextual metadata.
What are dynamic applications?
What are dynamic applications?
The simplest way to think about what a dynamic application is that it takes information in and using some advanced logic can then create different outputs that can cut down on the amount of domain specific logic needing to be developed.
We could think of this as being a pre-processor.
A really good example is to think about reporting development. A user who has a business requirement may ask for a data information team to develop some reports. Quite a lot of time will be spent thinking about how this report will need to be developed. This will require quite significant expertise on the part of the report developer and a good business understanding of the underlying data sources. In some situations, be very important to have developers who have expertise in developing specific displays. An alternative is that some applications can take information, and using intelligence provide data where the user can then perform self-service business intelligence on. The user may not have been aware, they just simply wanted different bits of data to be available for viewing.
Another example of a dynamic application could be a web application. If we think about the standard model view controller approach, it traditionally encapsulates the spirit of Domain Driven Design. We will have many views, models, and controller end points to match the domain specific requirements. We already touched upon this in an earlier discussion on domain based development. We may prefer to not put all of the domain logic inside a an MVC application. Instead, we may decide to develop the domain based logic inside the data model and also inside typical MVVM Web pages. There may be potential to generate these models on MVVM form data models. We may be able to write code to interprets data models to produce code for moving information between the database and application. Our objective is to reduce the amount of code inside the dynamic application which is decoupled from domain based logic.
A key advantage of taking a domain based approach separately from a more agnostic and dynamic application, is that dynamic application can be reuseable for other purposes. It won't get polluted by domain based logic. We focus on having configurable. Views and pages which can meet different purposes. We can potentially give requirements to external outsourcing companies who can develop domains, specific views and logic, which we can simply inject into our dynamic applications. This can offer massive advantages because suddenly we can have developers who are tightly coupled to understanding the domain based logic of an enterprise, and have other developers who are focused on the dynamic nature of providing services whereby domain based logic can be injected into it.
We can think of dynamic applications as in many ways being a modular approach with components being loadable into it. We can also think of dynamic applications as being able to interpret data with either some intelligence or configuration, perhaps both and to produce outputs which are useful to users and other applications.
Which is best, domain base development or dynamic applications?
We can't say for certain, But trends are emerging where a shift is more towards reducing codebase size. We don't want applications which have significant domain logic combined with component based functionality. We would be better served outsourcing or insourcing domain based development keeping separate dynamic applications to take that domain logic and service this to users and applications.
In this article we have highlighted there is more than just one way to implement large domain driven design applications within an enterprise. We have frequently seen applications start out purely from business requirements, and this leads to applications becoming what is known as the "big ball of mud".
We can reduce this sprawling architecture maintenance nightmare By hiving off and separating domain based development with more technical dynamic application components.
Over the last 20 years, in particular, the trend has been geared towards focusing on the business requirements, potentially using Agile methodology to streamline the development life cycle. Discussing the merits demerits of agile methodology within this document is out of scope. We assert that we must separate domain based development and dynamic applications. In many ways this would allow for any project methodology to focus the "habits"- the technical dynamic application requirements versus the traditional domain based requirements.