Domain Low Code Architecture (#DLCA)

TECHNOLOGY

Technology is the sum of technique Skills, Methods and processes. Advancement of technology is generally known as Modern Technology. Modern technology is all about agility, speed and efficiency. 

From 2020, the era will be of Data and Low Code which will take pace. Here, I am showcasing how Domain Low Code Architecture (#DLCA) can be implemented to achieve Agility, Time to Market, Shared Business Rules to ease development of sub-domains\customized Apps within organisation and easily turning new idea into action.

KEY ARCHITECTURE ASPECTS

These are 4 pillars stand on Lean-Agile ground which will help us to build Low Code Domain Architecture.

1. Domain Driven Design
2. Clean Architecture
3. Single Source of Truth
4. Low Code

Domain Driven Design aka DDD is a broad concept and it is challenging to come up with brief definition, as Eric Evans had to write a book with 560 pages in 2003 on this. :) 

Domain-Driven Design is the idea that a forward-looking software system can be built on domain model that has a rich understanding of the processes and rules of a domain. DDD secure the domain model, in domain terms, through interactions with domain experts and protect corruption of Domain knowledge by other domains, etc. In DDD, sub-domains are created in large or complex domain. These sub-domains are called as Bounded Context. Identification and classification of Bounded context is done by Context Mapping. Also, Ubiquitous Language, UL, is used for communication between software developers and domain experts as a common language which means UL needs to be build that embeds domain terminology into the software system. Building blocks of DDD also includes classifying objects into Entities, Value Objects, Service Objects and identifying the concept of Aggregates. As any other model, system should evolve DDD model implementation as best possible fit and not as perfection as they say “perfection is the enemy of good”.

Clean architecture drives to organize system that supports Agility (easy to change), Understand-ability and Scalability (easy to grow). 

Every architecture emphasizes on below characteristics to develop a system.  

·       Independence of frameworks: Use frameworks as tools, rather than forcing you to cram your system into their limited constraints.

·       Testable: The business rules can be tested without the UI, database, web server, or any other external element.

·       Independence of the UI: The UI can change easily, without changing the rest of the system. A web UI could be replaced with a console UI, for example, without changing the business rules.

·       Independent of the Database. You can swap out Oracle or SQL Server for Mongo, BigTable, CouchDB, or something else. Your business rules are not bound to the database.

·        Independent of any external agency: Business rules don’t know anything at all about the interfaces to the outside world.

Single Source of Truth (SSOT) is One view of data that everyone in a company agrees is the real, trusted number for some operating data. It is practice of structuring information is such a way that every data element is mastered in one place and any possible linkages to this data are by reference only. The information is arranged and defined such that there is no duplication and overlaps.

     Low-code is a modern way to build and continually improve business applications that better matches the business agility. A low-code model enables developers of varied experience levels to create applications using a visual user interface in combination with model-driven logic. This means that those closest to business problems can be empowered to quickly turn ideas into action, with simplicity of minimum possible code.

Domain Low Code Architecture (#DLCA)

Low code is not just Drag and drop visuals but writing or having minimum possible code. In DLCA, we emphasize on making service and database layer such a way that it can be shareable between different sub-domains at ease.

Below is snippet of Domain Low Code Architecture based on above four pillars on Lean-Agile ground.

Following are agile bucket catalogs to build DLCA system.

• 
  
  
  • Open Source Domain Services: Open source is not a synonym of “Free” but things available for public use. It might be free or can be consumed on subscription basis. It is one way to contribute in evaluation of domain which just keep evolving for good. Thus, being a Domain leader, we can identify which artifacts, application, data or APIs, can be exposed to other world and encourage shared community for development and innovation in domain. For example, a health data having age, gender, region, symptoms, season and diseases can be used for Data analytics which can help medical scientist to study at which age a increase in diseases has been recorded in specific gender category. An organization can capitalize by commercializing these open source artifacts.
  • Shared UI Components: Must have system’s operations like Authentication, Logging, Controller layer for service call, etc can be decoupled from system and developed as isolated component like DLL, Nuget package, etc such that it can be consumed by any other system within domain irrespective of platform i.e., consumable by Web, Mobile or Desktop applications. For example, a controller or abstract layer class that used to call API service can be created as a component and which can be absorb by any system followed by calling component function which them make a call to service layer. Naming convention at all levels (for e.g., namespace, class, etc) of these components should not have any sub-domain specific name/key words until and unless component is sub-domain specific like abstract layer to call sub-domain service layer. Yes, sub-domain specific component is also published as shared UI components so that for Domain aggregates can consume it and system has SSOT.
  • Low Code Frontend: Minimum possible code to generate front end UI. No business rule and service call logic should be written in front end UI solution. Business rule and service call logic should be absorbing or inherits from shared UI components.
  • Shared Core Business Rules: Some Domain business rules are same across sub-domain which called as Core business rules. For e.g., calculation of VAT, etc. These common rules should be deployed as shareable within domain. Every system must not write their own version of core business rules. Shared Core Business Rules will restrict them to do and will save extra effort to rewrite same logic again within domain.
  • Shared Data Services: Master data like Exchange rate, etc. is common across domain. Such data should be available to all sub-domain to consume from one source and Shared Data Services will do the same. Shared Data Services will allow any sub-domain system to access these data as read-only.
  • Shared Services: Notifications, File operations, http/s calls, etc are some common services that every system must have in todays era. These services can be placed at Shared services for sub-domain systems.
  • Sub-Domain Services: This is classic sub-domain microservices. However, some microservices can be made available for access to other sub-domain. It might be possible that some sub-domains want to consume specific information of other sub-domain within domain then it should be accessible for them.
  • Domain Database layer: Domain Database layer will be based on services catalog and support domain service layer. If database is deployed at cloud then it is very easy for scalability which drives to customize sub-microservices architecture and make a single database for 2 or more sub-domain given partitioning, data access rules, etc are in place.
  
  

A large or complex domain run multiple customized small systems to support their sub-domain which results extra development work for every common component that already implemented somewhere within domain and not to mention running considerably extra data processing to merge or save at Domain level database. For example, in a large or complex domain where one sub-domain is not communicating with another sub-domain. In this scenario, they will end up writing their own system logic and that can be controlled by them. This duplicate effort can be saved by implementing Internal open source catalog by using already developed component within domain like, sharing same tax calculation across sub-domain will ease down tax data correction at different data levels.

DLCA can help organization to Capitalize on already built components, foster culture of Open Source within domains, Encourage sub-domains to work as OneTeam and Maintain Single Source of Truth across domains that can lessen redundancy and confusion.