Core Design: Avoid coupling at the Core
* Write code
* Read code (a lot)
* Think about responsibilities
* Think about bringing things together
* Think about braking things apart
* Do and participate in Design Sessions
* Time and Experience
There are several schools out there like Services, OOP, FP, and many others. IMHO there are some CORE ideas that we can use besides your language, school of thought, and experience. Knowing what not to do is as much important as knowing what to do. For this blog post, I want to talk more about CORE Design.
The CORE
Every good software has a CORE. Often a CORE could be called by different names like Kernel(i.e Linux Kernel). Other names but not that commons are CORE and KERNEL are (Heart, Base, Parent, framework, or just implementation). What is CORE? Let's look at some definitions:
As you can see in Dictionary.com the CORE means the "Cental part" the "Essential part". Identifying the CORE part of your software means better focus and avoid coupling. Coupling is really the heart of all evil. We often (For commodity) try to couple concepts and solutions(For us or for others). Coupling is fine if done right and at the right level.
Why should I care about identifying the CORE of my solution?
There are several reasons why you dont want to couple your CORE solutions with the other parts. Modular design is a missing discipline nowadays. We often talk about Deployment units like Microservices VS Monolith but we spend little time to improve the whole design of solutions.
Why we need to Keep the CORE Lean and Clean:
* Easier to Reason about it. Lots of time complexity means code obscurity.
* Easier to USE and Re-use. Even if you dont have re-use I would keep the CORE clean.
* Easier to Test. Clean COREs tend to be very easy to be tested.
* Easier to Debug. Debuggability is an important matter since we maintain code for a longer time.
* Less coupling, meaning more freedom and fast interaction times.
How can I identify my CORE?
That should be fairly easy. he trick is not coupled things you dont need. Your core should be as clean as free of dependencies as possible. As much as possible not remote calls, no database calls, no external IO. That will depend on what you are doing, but most of the cases I would argue that it's true. Let's say you're making a solution to predict when someone should retire. The MATH is your core, not the database schema, not the remote calls, not your access devices like Web, Mobile, AR/VR or Audio Interfaces(like google home/Alexa). But you could argue IF I will make retirement predictions I need to have a MOBILE API or APP otherwise there is no value. True but that should be a different module. Because you want to re-use that MATH in the WEB or you dont want to change that just because Apple has an IOS bug or new version.
Could we think about what happens inside of a Service?
We often think about What services should we create. Valid questions, don't get me wrong but what about what happens inside the service? What about internal Design? We need to worry about that too. There are other approaches that tackle this problem as well.
Uncle Bob's Clean Architecture is one example of an approach thinking about that. One of the things I like about it is that the External Interfaces are lots of layers away from the CORE entities. However, thinking about the CORE is not a new IDEA. Look Linux Kernel for instance.
Linux Kernel is a good example of modules. Separation from the CORE from the REST of the system. You might be wondering if is that really necessary? When we realize that software is not going away the answer is YES. If you have a SHORT term thinking or a PROJECT mindset might think thats not needed. However when you understand that this is part of your digital products and in the long run this will affect your ability to deliver value to the business it becomes critical. Unfortunately, Good Design is like CAR insurance you can't get up after the fact(car crash).
Cheers,
Diego Pacheco
