The Advent of Code 2020 - thought process and conclusions

Stefan Pavlovic — Sun, 14 Feb 2021 00:45:43 +0000

This blog post will give some context for my future blog posts on this subject. I will write about the insights I got from AoC 2020.

Future posts will probably be shorter than this one and will go straight to the point. Also, I will try to focus on one subject per post.

For example, one of my future posts will be about using value objects instead of being obsessed with primitives and concrete examples in C#.

The form of my future posts will be following. What problem I got, how it is affecting my solution and code, how it can be solved (what value we will get), and how this problem will look on a larger scale.

How the advent of code works?

The advent of code 2020 is a coding challenge that is made of 25 days. Each day contains a challenge broke into multiple parts.

The fact that we first get only one part of the challenge without knowing in which way the requirement will change, or what will need to be added in future parts made me commit to this challenge.

I think this is an ideal environment for improving our thinking because this is really close to the real-world environment. Requirements are changing, existing code needs to be extended, new features that are written can change and we need to be prepared for this change.

Most important thing is that here, in AoC, we have a safe environment where we have the freedom to experiment.

In real-world applications, this isn't always the case. Also, in my opinion, it would not be responsible to experiment with production code.

What I am expecting to get from this challenge?

By the end of this challenge, and with each day solved, I am expecting to write better code.

Now what is better code?

In this case, better code will not be the most performant code that can be written, not this time.

Better code is readable, reusable, simple, and performant enough to satisfy business requirements. In other words, the best code we can write is code made of smart tradeoffs.

Getting maximum value from this challenge

Obviously, there is a broad scope of values that we can get, or not get, from working on AoC but my reasoning is the following.

These challenges can be solved fast. We can be fast when there is empty paper put in front of us.

The question is how to be constantly fast? How to be able to change fast? How to be able to change at all? How to change and be sure that everything is working as it should? How other developers that are looking at the work we already did can know what were our intentions? Can we make such a design and solution that will guide the developer which is changing it only in one, right, direction?

Questions are the answer in this case. I will try to achieve this.

I am not expecting to answer all of these questions, but we need to strive for perfection if we are thinking about ourselves as professionals.

Current status

I just "finished" with day 4 of AoC 2020. When I say finished, that means correct solutions are found, but does this means I am done with this code? Certainly not.

The code I wrote is still not "production-ready". I didn't yet prove an absence of bugs (unit tests), refactoring is needed on both "day level" and general AoC solution level, the solution can be improved in general, etc.

What to expect?

Atm, I am thinking about two subjects. Why immutability is a good thing and why not be obsessed with primitives (and use value objects).

If you are interested to hear more stay tunned :)

Domain Driven Design. First thoughts.

Stefan Pavlovic — Mon, 30 Sep 2019 21:20:52 +0000

I just started learning about DDD so I decided to write a post about it. Here are some thoughts and conclusions I have so far.

Main thing is decoupling business logic from rest of the system and creating healthy model. Creating healthy model consider a lot of talking with domain experts and understanding domain on level needed for creating successful software. We don’t have to understand low level details about domain but we need to recognize purpose of the software and to shape model around domain knowledge.

Ubiquitous language
It is all about finding same language with domain experts, developers that work on project, and basically all the people which are interacting with system in one or the other way. Main purpose is to precisely define terms and to avoid ambiguity. If it’s done right we will get more precise specifications, tasks, better domain model… This is done by defining terms and their “scopes” and sticking to use them.

Approach to architecture. Defining responsibilities and splitting project on logical layers.

We have presentation layer, application layer, domain layer, infrastructure layer. Those layers can communicate in one direction (with some exceptions), or in other words if layer A can communicate to layer B, layer B can’t communicate to layer A.

Application layer is responsible for high level logic. When we look at application layer we can see calls to “lower” levels (domain, infrastructure...). Logic in this layer should be easy to read. Also this is place where transaction scope and validation are handled. We are validating input arguments, opening transaction, doing some high level stuff and closing transaction so everything is atomic (this is just an example, transaction is not necessary nor all logic should be in transaction).
Domain layer is representation of business rules, validation handling (validation in context of domain) and everything that have business logic in it. As I understand, entities, value objects and services are also here. This layer is on same “depth” as infrastructure, both are called by application layer but domain layer can also call infrastructure.
Infrastructure layer is place where is done communication with external systems, storing and providing data (repositories)...

Beside from layers we have concepts of entities, value object, services and modules.

Entities are objects in our system that have lifecycle and we need to track their identity through time (we need to know which subscription is user payed for, never mind if that subscription package doesn’t exist anymore or its state is changed), and through all instances in our system if it is distributed system.
Other important thing that distinguish entities from other objects in our system is self-contained logic. Entities should be more than “bags of getters and setters”. They should have logic that define them in particular business context. Also they should have validations and maybe even defending mechanisms (initialization through factory) so they can’t be corrupted.
Value objects are objects in whose identity we don’t have interest and we don’t need to track instance identity through system. With introducing value objects in our system we gain on simplicity (we don’t track object that we don’t need to track). Also value objects don’t have lifecycle and that mean we can be flexible with decisions how we can use them.
There are basically two approaches for “using” value objects in our system and to choose which one to use depends on implementation environment. One is using copies of value object instance. That approach will clog application with huge number of objects. Second one is sharing same instance. Although this approach looks better it is expensive in distributed systems when we must pass reference to other services (possible other physical machines) and require some message back in each interaction. Copy is sent and it will leave independently on other machine.
Services are everything that doesn’t fit and doesn’t belong in entities. It can be business logic that take care of more entities and we can’t find place for it in that entities themselves.
Modules are basically grouped parts of the system that have some kind of relation (in domain logical sense). When we put few classes in module we are telling next developer who are looking in this module that those classes should be observed as a whole.

Other thoughts that I have in my head right now:

We should build our systems not based on UI. We should first think about domain model, how particular feature fits in it and how UI will follow it.
We should create environment that is easy to change and not break anything because of constant refactoring that is needed for better definition of domain model. This can be achieved with automated tests (unit tests, integration tests, smoke tests…).
We can start small, with monolith that have decoupled verticals, so we can later scale it into distributed system. By that I mean we should have decoupled modules, different database schemas... Also we should think about entities and their identity across many instances in distributed system.
We shouldn’t use DDD for really small project that will never be extended with more functionalities. In this case we should go with smart UI. Main reason for this is that DDD is expensive for this kind of projects.
DDD is hard to be “implemented” from unexperienced team of developers without some kind of leadership of developer experienced with DDD. It could escalate in smart UI and for complex systems that could be fatal.

Unknowns (so far):

Are modules “verticals” that can be later extracted to separate processes (distributed)? How modules communicate? How modules are “implemented” in system?
Where should be done registration of “services” in IOC container?
Where should be done mapping because we will have mappings that contains view models (for presentation layer), data transfer objects (DTO’s), data models (database/tables representation). Our mapper had to know about all of the layers so how we will use it without cross referencing? Where it should be registered for dependency injection and how different layers will consume it?

DDD is the only approach I found so far that have some historical feedback. What I mean by that? People were used it and it is proven to have many benefits if it’s done right.

DEV Community: Stefan Pavlovic