You must have seen a building surrounded by scaffolding.
Have you considered that with or without scaffold is exactly a symbol that splits the lifecycle of a building into two phases - being built and being used. It is very obvious that
- There are distinct concerns in these two phases, and
- The final goal is to use the building, not just to build it.
Although I am not a fan of “dualism”, I realized that, in many different areas, if the “scaffold” can be identified, it tends to make things clearer and finding appropriate solutions will be easier to approach challenges in two phases which split by scaffold.
Case 1 Git and automation tools
When I review “architecture design”, one thing I always notice is that the diagrams contain both “component structure” and “git/automation tools/pipeline”. In fact, git/automation tools/pipeline are exactly the scaffold of software. People use them to build the software. Once the software has been built, scaffold goes away and another phase starts. At this phase, it is code quality, architecture design and infrastructure that take an important role.
Combining these two phases will lead to confusion and make it hard to focus on a single goal - building software fast or keeping software running stable.
Case 2 Shared-Database Integration
To integrate two systems by using a shared database is a long-lived approach. The biggest advantage of it is easy for building. In the past decades, when software did not change as frequent as nowadays, building software with low cost was the key to success. However, today’s software must keep the cost of changing low, since changing software is much more frequent than building software. Shared-Database will be the hell of evolving the software.
The first release of the software is the breaking point. If there are no more releases, Shared-Database integration is a good choice. Otherwise, stay away from shared-database.
Case 3 DI
Any experienced OO (Object-Oriented) programmer must be familiar with DI (Dependency Injection). Every thing is an object in OO programming languages, so OO programmers spend lot of time handling the creating and disposing the objects, even the more valuable work for them should be using objects. There were several solutions designed to help developers focus on using objects instead of managing the life cycle of objects, such as Abstract Factory and Factory Method design patterns.
Among these solutions, DI is definitively the most graceful idea for separating managing objects from using objects. The clear separation can greatly improve the readability of source code and therefore reduce the number of odd defects.
Case 4 To define a concept
DDD (Domain-Driven Design) is indeed valued for its ability of identifying and using a ubiquitous language which contains several important concepts. These concepts will be shared among business people and software delivery people. But it is not easy to get these two groups of people to have the same understanding of a concept. It needs, in general, a long process to get the understanding fully aligned. So, the definition of a concept also has two phases split by “alignment”. If the concept is not aligned, the definition could be the description of how the concept generated. For example, “xxx master data” could refer to the file used by xxx team who delivers the file to others downstream departments. And once the concept is fully aligned, the definition could use mathematically precise notations. For instance, “xxx master data” refers to the information generated by process A and is later consumed by process B and C.
The approaches and concerns for with and without scaffold are not necessarily same. To treat them separately can often make things much clearer.
So, if you can identify the scaffold of your tasks, you might feel easier to handle the tasks and to achieve your final goal.