Executive Development Summary
1 Vision Domain Driven System development
This chapter describes how complex business and/or operational systems can be developed based on Message based Domain Driven Design architecture. This chapter describes the vision of the management. This document will help you in understanding vision we have on the development of complex systems either in interfacing with hardware, software or the complexity of big to be developed solutions.
The document will bring understanding why Message based Domain Driven Systems development between the different components is essential in building complex and still easy to maintain large software systems.
It will bring a thorough understanding how every component and tool fits into the Domain Driven System architecture.
1.1 Advantages of Domain Driven Software development.
Despite of all the ideas behind Domain Driven Software development which are not new and the advantages are for every one apparent. Maintainability, flexibility, efficiency in development, and many more simple reasons and advantages Domain Driven Development has not yet been adopted to the main market as a standard.
Without any real business reason it is common that every new software development is usually build based upon classic design, where user interface, business rules and proprietary interfaces with proprietary software and hardware is build within one big software solution.
One of the reasons comes from the technological limitations in hardware and software from the past. These reasons are however not viable anymore and Domain Driven Development should therefore be adopted for every new development.
1.2 Use of architectural language
It is a big problem when in projects within a team different terms and understanding is for business concepts. If technical employees (developers) need to make a translation between old fashion based developments does not differ a lot from Domain Based development, however there is a distinct difference between the mindset of development.
Commonly understandable architectural language is needed to make it for the developer understandable what the expectations are from a management point of view.
The Domain Driven Software development makes a difference in 4 distinctive different layers
- User Interface layer
- Application layer
- Domain layer
- Infrastructure layer
1.2.1 User Interface layer
These is the layer responsible for viewing information to an end user and for the interpretation of end-user commands like, add, edit, delete and view.
1.2.2 Application layer
In the classic development cycle this layer is responsible for the business logic. In the Domain Driven Software development this layer is does not have any business logic and/or rules it sole responsibility is to coordinate tasks (messages), delegation of such to the domain layer.
1.2.3 Domain layer
The domain layer is the layer where the actual business logic applicable is. This is the place for concepts and rules.
1.2.4 Infrastructure layer
This layer supplies technical services to the other layers.
WHATSUP has been designed and implemented with the previous layer architecture in mind.
.jpg)
2 WHATSUP
2.1 What does WHATSUP mean
What's-up is an acronym for (W)arning, (H)ost, (A)larm, (T)ask, (Sup)port - system.
2.2 Where is WHATSUP used
3 WHATSUP Global overview
In above global overview you can see the applied Domain Driven Architecture. This Domain Driven Design has been met due to the distinct difference in the different layers.
From top to bottom we will discuss the different layers applied in the WHATSUP architecture.
3.1 FID (Flexible Interface Designer)
This layer has been implemented with a FID the flexible interface designer. Based on the XML schema's used in the next layer (Messaging /HMI) the FID designer can flexibly build user interface screens. The FID is only responsible for the displaying, editing of the data made available by the Messaging / HMI layer.
The FID cannot handle any business logic. The FID shows the data from the XML message in a form and sends the data back to the Messenger / HMI layer for processing.
3.2 Messaging / HMI
The Messaging HMI layer is responsible for the processing of the data in XML. The HMI processes the data based upon Agent directives. By means of Agents the data is directed to the right process. The HMI also contains a workflow management system for Agents. Based on the interaction between Agents and the workflow the business process is structured to interface between the next layer the business and operational procedures and 3rd party software/hardware.
3.3 Business and operational procedures / 3rd party software/hardware
This layer exists out of proprietary software, API (Application Programming Interfaces), 3rd party customized tailor made software and/or other business and/or software based on commercial of the shelve hardware and/or specific hardware.
This layer interacts with the specific developed Agent functionality.
3.4 OS High availability / Fail Over / Fault tolerant / Virtual Machines
OS is usually part of the infrastructure layer, however as the OS here has been designed as a high availability, fail over, fault tolerant and with virtual machines. This has become a separate layer as the functionality of this layer is distinctly different from the normal OS functionality usually part of the infrastructure layer. The ability to make use of this layer in Business and operational procedures and the HMI through messaging makes this a separate layer.
The OS HA layer can be managed from the HMI and maintained.
3.5 Infrastructure Hardware
This layer is completely separated from the layers above. This Domain Driven Architecture must be hardware independent. Hardware should in no case be a limitation in the design of any business and/or operational solution towards the end-user.
4 Implementing WHATSUP / Domain Driven Development
This chapter will explain how WHATSUP and Domain Driven Development must be used in the development of complex business and/or operational solutions.
4.1 Before you start
Change your mind set.
4.2 Design requirements
4.2.1 Commercial of the shelve / Proprietary Software
4.2.2 Development
4.2.3 Commercial of the shelve / Proprietary Hardware
4.2.4 Implementing
4.3 Your first HMI steps
4.3.1 HMI specification
4.3.2 What are Agents
4.3.3 Developing an Agent
4.3.4 Implementing an Agent
4.4 Interfacing with the user
4.4.1 The user interface
4.4.2 Working with FID
4.5 Deployment
