Step 0: Analyze Your Business Domain
Your Type of Project
Working on a complex software system, you always implement a special type of architecture:
- Data Driven Architecture: DataBase, Persistency, GUI, Business Objects, Relationship between Business Objects
- Machine Control Architecture: Realtime System, Memory Management, Threading, GUI, Algorithm, Components, Commands, Command Data, Relationship between Components
- Event Driven Architecture: Communication, IO, Dispatcher, Multiplexer, Event Source, Event Handler, Event Data
- Service Oriented Architecture: Heterogeneous Environment, Communication, Services, Service Data
- ...
Your Software Architecture
Lenn Bass has the following widely accepted definition of software architecture:
This seems a rather general definition. Does it help? Yes, it says that we do have components and relationship between them. You may have noticed that there are some bold terms in the paragraph above. Just think for a moment, what is common about them.
The bold term are concepts that are realized over and over again. Deciding us for a Service Oriented Architecture, it is for sure that we have to implement lots of Services communicating by exchanging specific Service Data. Realizing a Data Driven Architecture it seems obvious to implement lots of Business Objects, which do have specific Relationships to other Business Objects.
- The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components and the relationship among them.
This seems a rather general definition. Does it help? Yes, it says that we do have components and relationship between them. You may have noticed that there are some bold terms in the paragraph above. Just think for a moment, what is common about them.
The bold term are concepts that are realized over and over again. Deciding us for a Service Oriented Architecture, it is for sure that we have to implement lots of Services communicating by exchanging specific Service Data. Realizing a Data Driven Architecture it seems obvious to implement lots of Business Objects, which do have specific Relationships to other Business Objects.
Implementing a Concept
As we said before, the bold terms are concepts, which have to be implemented over and over again. An architecture may contain instructions how to do that correctly. But the specific implementation is always done manually by a developer.
Let's implement a specific PatientService for example. Modern Software Architectures structure technical topics in tiers. On the one hand, working with tier structures your complex software system quite well. On the other hand, implementing a new Service will usually force you to write code for every tier:
This problem is known as feature delocalization: every tier needs more or less the same information:
To give a resume:
Sounds like a lot of work? It is a lot of work! Tedious and error prone. But it is the work of a software developer today.
Let's implement a specific PatientService for example. Modern Software Architectures structure technical topics in tiers. On the one hand, working with tier structures your complex software system quite well. On the other hand, implementing a new Service will usually force you to write code for every tier:
- Visualization
- Business
- Persistency
- Communication
- ...
This problem is known as feature delocalization: every tier needs more or less the same information:
- The name of the service
- The Request Service Data containing data fields
- The Response Service Data containing data fields
- ...
To give a resume:
- For every specific Service and for every tier, we have to write code.
Sounds like a lot of work? It is a lot of work! Tedious and error prone. But it is the work of a software developer today.
Do it actifsource!
Imagine, there is way to describe the attributes and relations of a service!
This is what we call the actifsource Meta Model.
Imagine, that there is a way, to provide all necessary information for a specific Service only once!
This is what we call the actifsource Domain Model.
Imagine, that you may code your service only once - no matter how many implementations you need at last. That's because any service implementation is similar anyway!
This is what we call Generic Programming using the actifsource Template Editor.
And imagine, that all the code for every tier is generated automatically if anything changes in your Meta Model, your Domain Model or your Template!
This is what actifsource is all about! Generating your code structure along your Domain Specific Software Architecture.
This is what we call the actifsource Meta Model.
Imagine, that there is a way, to provide all necessary information for a specific Service only once!
This is what we call the actifsource Domain Model.
Imagine, that you may code your service only once - no matter how many implementations you need at last. That's because any service implementation is similar anyway!
This is what we call Generic Programming using the actifsource Template Editor.
And imagine, that all the code for every tier is generated automatically if anything changes in your Meta Model, your Domain Model or your Template!
This is what actifsource is all about! Generating your code structure along your Domain Specific Software Architecture.
