DEV Community: Julian Lasso 🇨🇴

How to install Docker CLI on Windows without Docker Desktop and not die trying

Julian Lasso 🇨🇴 — Wed, 27 Mar 2024 19:59:15 +0000

In this post, we will explore how to install and configure Docker CLI on Windows without the need for Docker Desktop. Although Docker Desktop is a convenient and popular tool for managing Docker containers in development environments, there are situations where a lighter or more specific alternative is preferred or required. Whether due to licensing restrictions, minimal resource needs, or personal preferences, installing only Docker CLI can be the ideal solution. I will guide you through the necessary steps to set up your Windows environment to use Docker CLI, leveraging the capabilities of WSL 2 (Windows Subsystem for Linux version 2) and without the overhead of Docker Desktop. This will not only provide you with more granular control over your Docker containers but will also optimize resource usage on your machine.

Preliminary steps for installation

The following steps have been tested on Windows 10, but I assume they will work the same for Windows 11.

The first thing to do is to install WSL, and for that, open a PowerShell console and type the following command.

wsl --install

After the previous step, you need to restart the operating system.

Note: As I read, the following command does the same but additionally restarts the computer when it finishes the necessary installation.
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

When the computer has restarted, a window like the following will open:

After waiting for some time, an English message will appear, which will tell you to enter the username for your Linux user and will also ask for the password. Write down your username and password carefully because we will need them later.

Once it has finished successfully, then it's time to start installing the Docker CLI and we will be located in the console of our Linux distribution.

Note: It's important to keep in mind that the distribution installed by default is Ubuntu 22 at the time of writing this tutorial.

Once at this point, the first thing to do is to update the repositories and programs of the distribution with the following command:

sudo apt update && sudo apt upgrade

This action will request the password that we assigned to our user.

Note: don't forget to say yes (press Y) to confirm that you want to proceed with installing the updates.

Adding the official Docker CLI repository

When the updates are finished, then we will run the following command to perform some necessary installations prior to Docker CLI.

sudo apt -y install apt-transport-https ca-certificates curl gnupg lsb-release

After that, we will run the following command to add the necessary signature for the Docker CLI repository.

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

Now it's time to add the Docker CLI repository in Ubuntu for its subsequent installation with the following command.

echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Installing Docker CLI

Since we now have the Docker CLI repository ready, it's time to do the required installation with the following command:

sudo apt update && sudo apt -y install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin docker docker-compose

At this point, we now have Docker CLI installed in our WSL, let's test it with the following commands:

docker --version
docker-compose --version

We should get a response similar to the one in the following image:

How to run Docker without root user

Now we will create the docker group and add our user to that group so our user can run containers without needing to run commands as root.

sudo groupadd docker
sudo usermod -aG docker $USER
newgrp docker

Note: When you try to create the docker group, you will probably get a message saying the group already exists. If that's the case, don't worry, just proceed.

Now what we need to do is start Docker and verify it's working correctly, and for that we'll use the following commands:

sudo service docker start
sudo service docker status
docker run hello-world

When you run the sudo service docker status command, you'll get something like the following image:

To exit that, press the Q key

When using the docker run hello-world command, you may receive a message like the one in the following image:

Don't forget to run the following command and then run the Docker hello-world again:

newgrp docker

Now if everything went well, you should get an image like the following when running the Docker hello-world:

With everything we've done previously, it's time to make this work "natively" in Windows through PowerShell.

Docker in the PowerShell console

Now that Docker is installed, it's time to make it work in the PowerShell console. At the moment, Docker works great but in the console of our WSL.

When opening a PowerShell console we can use the following commands:

wsl docker --version 
wsl docker-compose --version

The idea is that we can use the commands but without the wsl prefix. To do this, we need to modify the Microsoft.PowerShell_profile.ps1 file, but to know where to create it, we should run the following command in a PowerShell console:

echo $PROFILE

As you can see in the previous image, it shows a path and if you check that path, it probably won't exist. Well, we must create those folders and the file itself. Once you've done that, you should put the following text in the file:

Function Start-WslDocker {
    wsl docker $args
}

Function Start-WslDockerCompose {
    wsl docker-compose $args
}

Set-Alias -Name docker -Value Start-WslDocker

Set-Alias -Name docker-compose -Value Start-WslDockerCompose

With the above, don't forget to close the PowerShell consoles and reopen them so they take the changes. And with that, we should be able to run the following Docker commands normally in the PowerShell console:

docker --version
docker ps
docker-compose --version

Visual managers

If somehow you don't like managing Docker from the console, but you long for a visual manager in the style of Docker Desktop, then I have two very powerful and free solutions for both personal and business use.

Portainer CE (Community Edition) is a lightweight service delivery platform for containerized applications that facilitates the management of Docker, Swarm, Kubernetes, and ACI environments. This is an open-source project with community support, offering a free option for both businesses and personal use.

Lazydocker is a simple terminal UI for both docker and docker-compose, written in Go with the gocui library. Its goal is to simplify Docker management, making it more accessible and less tedious for those who prefer to work from the terminal. It provides a clear overview of Docker containers, images, and volumes, allowing users to perform common actions with just a keypress or click, making it an efficient tool for both personal and business use. As an open-source project, Lazydocker is a free option that facilitates uncomplicated Docker management, making it ideal for personal and business use.

Final conclusions

As you can see, the Docker CLI can be managed in Windows without the need to rely on Docker Desktop, and easily through the console.

References

Cómo instalar Docker CLI en Windows sin Docker Desktop y no morir en el intento

Julian Lasso 🇨🇴 — Tue, 19 Mar 2024 15:50:50 +0000

En este post, exploraremos cómo instalar y configurar Docker CLI en Windows sin la necesidad de Docker Desktop. Aunque Docker Desktop es una herramienta conveniente y popular para manejar contenedores Docker en entornos de desarrollo, hay situaciones en las que se prefiere o se requiere una alternativa más ligera o específica. Ya sea por restricciones de licencia, necesidades de recursos mínimos o preferencias personales, instalar solo Docker CLI puede ser la solución ideal. Te guiaré a través de los pasos necesarios para configurar tu entorno Windows para usar Docker CLI, aprovechando las capacidades de WSL 2 (Subsistema de Windows para Linux versión 2) y sin la sobrecarga de Docker Desktop. Esto no solo te proporcionará un control más granular sobre tus contenedores Docker, sino que también optimizará el uso de recursos en tu máquina.

Pasos Previos a la instalación

Los siguientes pasos los he probado en Windows 10, pero supongo funcionarán igual para windows 11.

Lo primero que hay que hacer es instalar el wsl y para ello abre una consola de PowerShell y escribe el siguiente comando

wsl --install

Después del paso anterior, hay que reiniciar el sistema operativo.

Nota: Según leo, el siguiente comando hace lo mismo pero adicional reinicia el computador cuando termina de hacer la instalación necesaria.
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Cuando el computador se haya reiniciado, se abrirá una ventana como la siguiente

Después de esperar un tiempo, saldrá un mensaje en inglés, que te dirá que introduzcas el nombre de usuario para tu usuario en linux y también pedirá la contraseña. Anota muy bien tu usuario y contraseña porque lo necesitaremos más adelante.

Una vez se haya terminado con éxito, entonces llega el momento de empezar a instalar Docker CLI y estaremos ubicados en la consola de nuestra distribución linux.

Nota: es importante tener presente que la distribución que se instala por defecto es Ubuntu 22 al momento de escribir este tutorial.

Una vez en este punto, lo primero que hay que hacer, es actualizar los repositorios y los programas de la distribución con el siguiente comando

sudo apt update && sudo apt upgrade

Esta acción solicitará la contraseña que asignamos a nuestro usuario.

Nota: no olvide decir que si (tecla Y) para confirmar que se desea realizar la instalación de las actualizaciones.

Agregando el repositorio oficial de Docker CLI

Cuando ya se termine de hacer las actualizaciones, entonces ejecutaremos el siguiente comando para realizar unas instalaciones necesarias previas a Docker CLI.

sudo apt -y install apt-transport-https ca-certificates curl gnupg lsb-release

Después ejecutaremos el siguiente comando para agregar la firma necesaria para el repositorio de Docker CLI.

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

Llegó el momento de agregar el repositorio en Ubuntu de Docker CLI para su posterior instalación con el siguiente comando.

echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Instalando Docker CLI

Como ahora tenemos el repositorio de Docker CLI listo, es momento de hacer la instalación requerida con el siguiente comando

sudo apt update && sudo apt -y install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin docker docker-compose

En este punto ya tenemos Docker CLI instalado en nuestro WSL, vamos a probarlo con los siguientes comandos.

docker --version
docker-compose --version

Deberíamos tener una respuesta similar a la de la siguiente imagen.

Cómo hacer que Docker ejecute con el usuario normal

Ahora vamos a crear el grupo docker y agregamos nuestro usuario a dicho grupo para que nuestro usuario pueda ejecutar los contenedores sin necesidad de ejecutar los comandos como un root.

sudo groupadd docker
sudo usermod -aG docker $USER
newgrp docker

Nota: cuando se intente crear el grupo docker, probablemente salga un mensaje que diga que el grupo ya existe, sí es así, no te preocupes, sigue adelante.

Ahora lo que necesitamos hacer es iniciar Docker y comprobar su correcto funcionamiento y para ello usaremos los siguientes comandos.

sudo service docker start
sudo service docker status
docker run hello-world

Cuando se corre el comando sudo service docker status se obtiene algo como la siguiente imagen.

Para salir de esa parte, presionas la tecla Q

Cuando se usa el comando docker run hello-world probablemente puedes recibir un mensaje como el de la siguiente imagen.

No olvides correr el siguiente comando y vuelves a correr el hola mundo de Docker.

newgrp docker

Ahora si todo ha salido bien, deberías obtener una imagen como la siguiente al correr el hola mundo de Docker.

Con todo lo que hemos realizado anteriormente, es momento de hacer que esto funciones de forma "nativa" en Windows a través de la PowerShell.

Docker bajo la consola de PowerShell

Ahora que Docker está instalado, es momento de hacerlo funcionar en la consola de la PowerShell. En estos momentos Docker funciona muy bien pero en la consola de nuestro WSL.

Al abrir una consola de PowerShell podemos usar los siguientes comandos.

wsl docker --version
wsl docker-compose --version

La idea es que podamos usar los comandos pero sin el prefijo wsl. Para hacer esto, el archivo Microsoft.PowerShell_profile.ps1 pero para saber dónde lo creamos, deberíamos ejecutar el siguiente comando en una consola de PowerShell

echo $PROFILE

Como podrás observar en la imagen anterior, esta muestra una ruta y si verificas dicha ruta, probablemente no existirá, pues bien, debemos crear dichas carpetas y el archivo como tal. Una vez lo hayas realizado, deberías poner el siguiente texto en el archivo.

Function Start-WslDocker {
    wsl docker $args
}

Function Start-WslDockerCompose {
    wsl docker-compose $args
}

Set-Alias -Name docker -Value Start-WslDocker

Set-Alias -Name docker-compose -Value Start-WslDockerCompose

Con lo anterior, no olvide cerrar las consolas de PowerShell y volverlas a abrir para que tomen los cambios. Y con lo anterior deberíamos poder ejecutar los siguientes comandos de Docker con total normalidad en la consola PowerShell.

docker --version
docker ps
docker-compose --version

Gestores visuales

Sí de alguna forma no le gusta gestionar Docker desde consola, sino que añora un gestor visual al mejor estilo Docker Desktop, entonces le tengo dos soluciones muy poderosas y gratuitas tanto a nivel personal como a nivel empresarial.

Portainer CE (Comunity Edition) es una plataforma web ligera de entrega de servicios para aplicaciones contenerizadas que facilita la gestión de Docker, Swarm, Kubernetes y entornos ACI. Este es un proyecto de código abierto y cuenta con el apoyo de la comunidad, ofreciendo una opción gratuita tanto para empresas como para uso personal.

Lazydocker es una interfaz de usuario en terminal simple tanto para docker como para docker-compose, escrita en Go con la biblioteca gocui. Su objetivo es simplificar la gestión de Docker, haciendo que sea más accesible y menos tedioso para aquellos que prefieren trabajar desde la terminal. Proporciona una visión general clara de los contenedores, imágenes y volúmenes de Docker, permitiendo a los usuarios realizar acciones comunes con solo presionar una tecla o hacer clic, lo que lo convierte en una herramienta eficiente tanto para uso personal como empresarial. Al ser un proyecto de código abierto, Lazydocker es una opción gratuita que facilita la gestión de Docker sin complicaciones, haciéndolo ideal para uso personal y empresarial.

Conclusiones finales

Como pueden ver, Docker CLI si puede ser gestionado en Windows sin la necesidad de depender de Docker Desktop y de forma fácil y sencilla a través de la consola.

Referencias

Clean Architecture (Application Layer)

Julian Lasso 🇨🇴 — Tue, 26 Sep 2023 16:17:43 +0000

Continuing from the previous post about "Clean Architecture (Domain Layer)", it's the perfect time to delve deep into what the application layer entails in this architectural context.

What Does the Application Layer Entail?

The Application Layer can be considered the epicenter of the project. As its name suggests, it's in this stratum where the application is developed in its tangible form, bringing to life the logic previously defined in the domain layer. In other words, it's the space where use cases are materialized and executed, ultimately defining the application's behavior.

In this layer, I've focused on the following crucial aspects, including:

Commands and Their Validators: Here, commands represent the actions that can be performed within the domain. Validators play a fundamental role in ensuring that the parameters provided to these commands are correct and comply with defined rules.

Use Cases: The Application Layer is where the core logic of the application is concretely implemented. These use cases describe specific scenarios in which the main functionality of the application is used to achieve specific goals.

Persistence: Although the application is not directly connected to a database or other persistence systems at this stage, abstract classes and interfaces are defined here that the future infrastructure layer will use to manage data persistence. This ensures a smooth transition to the infrastructure layer when needed.

You can find the repository for the application layer at the following link, where I have achieved 99% unit test coverage:

Application Layer Repository

Structure

Here is the current structure of the domain layer:



📦src

 ┣ 📂commands

 ┃ ┣ 📂inputs

 ┃ ┃ ┣ 📜complete-to-do-command.input.ts

 ┃ ┃ ┣ 📜create-to-do-command.input.ts

 ┃ ┃ ┣ 📜create-user-command.input.ts

 ┃ ┃ ┣ 📜get-all-to-dos-command.input.ts

 ┃ ┃ ┣ 📜index.ts

 ┃ ┃ ┗ 📜login-command.input.ts

 ┃ ┣ 📂validators

 ┃ ┃ ┣ 📂base

 ┃ ┃ ┃ ┣ 📜index.ts

 ┃ ┃ ┃ ┗ 📜validator.base.ts

 ┃ ┃ ┣ 📜complete-to-do.validator.ts

 ┃ ┃ ┣ 📜create-to-do.validator.ts

 ┃ ┃ ┣ 📜get-all-to-dos.validator.ts

 ┃ ┃ ┣ 📜index.ts

 ┃ ┃ ┣ 📜login.validator.ts

 ┃ ┃ ┗ 📜new-user.validator.ts

 ┃ ┣ 📜complete-to-do.command.ts

 ┃ ┣ 📜create-to-do.command.ts

 ┃ ┣ 📜get-all-to-dos.command.ts

 ┃ ┣ 📜index.ts

 ┃ ┣ 📜login.command.ts

 ┃ ┗ 📜new-user.command.ts

 ┣ 📂common

 ┃ ┣ 📂config

 ┃ ┃ ┣ 📜app.config.ts

 ┃ ┃ ┗ 📜index.ts

 ┃ ┣ 📂enums

 ┃ ┃ ┣ 📜config.enum.ts

 ┃ ┃ ┣ 📜db-order.enum.ts

 ┃ ┃ ┗ 📜index.ts

 ┃ ┣ 📂exceptions

 ┃ ┃ ┣ 📜application.exception.ts

 ┃ ┃ ┗ 📜index.ts

 ┃ ┣ 📂interfaces

 ┃ ┃ ┣ 📜index.ts

 ┃ ┃ ┣ 📜jwt-data-user.intertface.ts

 ┃ ┃ ┗ 📜query-options.interface.ts

 ┃ ┣ 📂libs

 ┃ ┃ ┣ 📂jwt

 ┃ ┃ ┃ ┣ 📂interface

 ┃ ┃ ┃ ┃ ┣ 📜index.ts

 ┃ ┃ ┃ ┃ ┣ 📜jwt-header.interface.ts

 ┃ ┃ ┃ ┃ ┣ 📜jwt.interface.ts

 ┃ ┃ ┃ ┃ ┗ 📜payload.interface.ts

 ┃ ┃ ┃ ┣ 📜index.ts

 ┃ ┃ ┃ ┗ 📜jwt.lib.ts

 ┃ ┃ ┗ 📜index.ts

 ┃ ┗ 📜index.ts

 ┣ 📂persistence

 ┃ ┣ 📂exceptions

 ┃ ┃ ┣ 📜index.ts

 ┃ ┃ ┗ 📜persistence.exception.ts

 ┃ ┣ 📂models

 ┃ ┃ ┣ 📂base

 ┃ ┃ ┃ ┣ 📜document.base.ts

 ┃ ┃ ┃ ┗ 📜index.ts

 ┃ ┃ ┣ 📜index.ts

 ┃ ┃ ┣ 📜to-do.mode.ts

 ┃ ┃ ┗ 📜user.mode.ts

 ┃ ┣ 📂repositories

 ┃ ┃ ┣ 📂base

 ┃ ┃ ┃ ┣ 📜index.ts

 ┃ ┃ ┃ ┗ 📜repository.base.ts

 ┃ ┃ ┣ 📜index.ts

 ┃ ┃ ┣ 📜to-dos.repository.ts

 ┃ ┃ ┗ 📜users.repository.ts

 ┃ ┗ 📜index.ts

 ┣ 📂use-cases

 ┃ ┣ 📂base

 ┃ ┃ ┣ 📜index.ts

 ┃ ┃ ┗ 📜use-case.base.ts

 ┃ ┣ 📜complete-to-do.use-case.ts

 ┃ ┣ 📜create-to-do.use-case.ts

 ┃ ┣ 📜create-user.use-case.ts

 ┃ ┣ 📜get-all-to-dos.use-case.ts

 ┃ ┣ 📜index.ts

 ┃ ┗ 📜login.use-case.ts

 ┣ 📜app.ts

 ┗ 📜index.ts

Diagrams

If, for any reason, you don't wish to review the code, here are modeling diagrams for the most relevant sections.

Application and Use Cases

Commands, Inputs, and Validators

JWT Handling Library

Persistence

What's Next?

The next step is to establish the infrastructure layer, and for that, I'll be working with NestJs, TypeOrm, and PostgreSQL. However, it's important to note that, in theory, the choice of framework, ORM, and the type of database should be transparent to the application layer.

Additionally, it's important to mention that in this application layer, I have used Zod for data validation. Ideally, and in theory, we should avoid any dependencies on external libraries. In this regard, the ideal practice would be to develop our own validation engine, an option I will consider at a later time.

Final Words

As always, I appreciate any doubts, questions, concerns, or contributions you may have.

I am completely open to receiving any kind of feedback. Please don't hesitate to contact me; I will be delighted to hear your comments.

Arquitectura limpia (capa de aplicación)

Julian Lasso 🇨🇴 — Tue, 26 Sep 2023 15:57:19 +0000

Dando continuidad a la publicación anterior sobre la "Arquitectura Limpia (Capa de Dominio)", es el momento propicio para explorar a fondo lo que conlleva la capa de aplicación en este contexto arquitectónico.

¿Qué implica la capa de aplicación?

La Capa de Aplicación puede considerarse como el epicentro del proyecto. Tal como sugiere su nombre, es en este estrato donde se desarrolla la aplicación en su forma tangible, dando vida a la lógica previamente definida en la capa de dominio. En otras palabras, es el espacio donde se materializan los casos de uso que, en última instancia, definen el comportamiento de la aplicación.

Esta capa me he centrado en los siguientes aspectos cruciales, que incluyen:

Comandos y sus Validadores: Aquí, los comandos representan los datos que requiere el dominio. Los validadores desempeñan un papel fundamental al verificar que los parámetros proporcionados a estos comandos sean correctos y cumplan con las reglas definidas en la lógica del dominio.

Casos de Uso: La presente capa es el lugar donde se implementa de manera concreta la lógica central de la aplicación. Estos casos de uso describen escenarios específicos en los que se utiliza la funcionalidad principal de la aplicación para lograr objetivos específicos.

Persistencia: Aunque en esta etapa la aplicación aún no se conecta directamente a una base de datos u otros sistemas de persistencia, aquí he definido las clases abstractas e interfaces que la futura capa de infraestructura utilizará para gestionar la persistencia de datos. Esto asegura una transición fluida hacia la capa de infraestructura cuando sea necesario.

Puedes encontrar el repositorio de la capa de aplicación en el siguiente enlace, donde he logrado una cobertura del 99% en pruebas unitarias:

https://github.com/ProfeJulianLasso/todo-backend-application

Estructura

Lo siguiente es la estructura actual de la capa de dominio

📦src
 ┣ 📂commands
 ┃ ┣ 📂inputs
 ┃ ┃ ┣ 📜complete-to-do-command.input.ts
 ┃ ┃ ┣ 📜create-to-do-command.input.ts
 ┃ ┃ ┣ 📜create-user-command.input.ts
 ┃ ┃ ┣ 📜get-all-to-dos-command.input.ts
 ┃ ┃ ┣ 📜index.ts
 ┃ ┃ ┗ 📜login-command.input.ts
 ┃ ┣ 📂validators
 ┃ ┃ ┣ 📂base
 ┃ ┃ ┃ ┣ 📜index.ts
 ┃ ┃ ┃ ┗ 📜validator.base.ts
 ┃ ┃ ┣ 📜complete-to-do.validator.ts
 ┃ ┃ ┣ 📜create-to-do.validator.ts
 ┃ ┃ ┣ 📜get-all-to-dos.validator.ts
 ┃ ┃ ┣ 📜index.ts
 ┃ ┃ ┣ 📜login.validator.ts
 ┃ ┃ ┗ 📜new-user.validator.ts
 ┃ ┣ 📜complete-to-do.command.ts
 ┃ ┣ 📜create-to-do.command.ts
 ┃ ┣ 📜get-all-to-dos.command.ts
 ┃ ┣ 📜index.ts
 ┃ ┣ 📜login.command.ts
 ┃ ┗ 📜new-user.command.ts
 ┣ 📂common
 ┃ ┣ 📂config
 ┃ ┃ ┣ 📜app.config.ts
 ┃ ┃ ┗ 📜index.ts
 ┃ ┣ 📂enums
 ┃ ┃ ┣ 📜config.enum.ts
 ┃ ┃ ┣ 📜db-order.enum.ts
 ┃ ┃ ┗ 📜index.ts
 ┃ ┣ 📂exceptions
 ┃ ┃ ┣ 📜application.exception.ts
 ┃ ┃ ┗ 📜index.ts
 ┃ ┣ 📂interfaces
 ┃ ┃ ┣ 📜index.ts
 ┃ ┃ ┣ 📜jwt-data-user.intertface.ts
 ┃ ┃ ┗ 📜query-options.interface.ts
 ┃ ┣ 📂libs
 ┃ ┃ ┣ 📂jwt
 ┃ ┃ ┃ ┣ 📂interface
 ┃ ┃ ┃ ┃ ┣ 📜index.ts
 ┃ ┃ ┃ ┃ ┣ 📜jwt-header.interface.ts
 ┃ ┃ ┃ ┃ ┣ 📜jwt.interface.ts
 ┃ ┃ ┃ ┃ ┗ 📜payload.interface.ts
 ┃ ┃ ┃ ┣ 📜index.ts
 ┃ ┃ ┃ ┗ 📜jwt.lib.ts
 ┃ ┃ ┗ 📜index.ts
 ┃ ┗ 📜index.ts
 ┣ 📂persistence
 ┃ ┣ 📂exceptions
 ┃ ┃ ┣ 📜index.ts
 ┃ ┃ ┗ 📜persistence.exception.ts
 ┃ ┣ 📂models
 ┃ ┃ ┣ 📂base
 ┃ ┃ ┃ ┣ 📜document.base.ts
 ┃ ┃ ┃ ┗ 📜index.ts
 ┃ ┃ ┣ 📜index.ts
 ┃ ┃ ┣ 📜to-do.mode.ts
 ┃ ┃ ┗ 📜user.mode.ts
 ┃ ┣ 📂repositories
 ┃ ┃ ┣ 📂base
 ┃ ┃ ┃ ┣ 📜index.ts
 ┃ ┃ ┃ ┗ 📜repository.base.ts
 ┃ ┃ ┣ 📜index.ts
 ┃ ┃ ┣ 📜to-dos.repository.ts
 ┃ ┃ ┗ 📜users.repository.ts
 ┃ ┗ 📜index.ts
 ┣ 📂use-cases
 ┃ ┣ 📂base
 ┃ ┃ ┣ 📜index.ts
 ┃ ┃ ┗ 📜use-case.base.ts
 ┃ ┣ 📜complete-to-do.use-case.ts
 ┃ ┣ 📜create-to-do.use-case.ts
 ┃ ┣ 📜create-user.use-case.ts
 ┃ ┣ 📜get-all-to-dos.use-case.ts
 ┃ ┣ 📜index.ts
 ┃ ┗ 📜login.use-case.ts
 ┣ 📜app.ts
 ┗ 📜index.ts

Diagramas

Sí por alguna razón no deseas revisar el código, aquí te dejo los diagramas de modelado de los apartados más relevantes.

Aplicación y casos de uso

Comandos, inputs y validadores

Librería para el manejo de JWT

Persistencia

¿Qué hace falta?

El próximo paso es establecer la capa de infraestructura, y para ello, trabajaré con NestJs, TypeOrm y PostgreSQL. Sin embargo, es importante destacar que, en teoría, la elección del Framework, ORM y el tipo de base de datos debería ser transparente para la capa de aplicación.

Además, es importante mencionar que en esta capa de aplicación, he utilizado Zod para la validación de datos. Idealmente, y en teoría, deberíamos evitar cualquier tipo de dependencia de bibliotecas externas. En este sentido, la práctica ideal sería desarrollar nuestro propio motor de validación, una opción que consideraré en un momento posterior.

Palabras finales

Como siempre agradezco cualquier duda, pregunta, inquietud o aporte que desees realizar.

Estoy totalmente abierto a recibir cualquier tipo de retroalimentación. No dudes en contactarme, estaré encantado de recibir tus comentarios.

Clean Architecture (Domain Layer)

Julian Lasso 🇨🇴 — Tue, 19 Sep 2023 17:24:35 +0000

In this post, I want to share my approach to developing the domain layer, applying the principles I've learned from the book "Clean Architecture" by Robert C. Martin, as well as some concepts extracted from "Domain-Driven Design Distilled" by Vaughn Vernon.

Clean Architecture	Domain-Driven Design Distilled

For this layer, I've used my small boilerplate, which you can check out at the following link: https://dev.to/julianlasso/typescript-boilerplate-l9c

What's all this about?

My current project involves developing a To-Do application with user authentication. Despite being a seemingly straightforward task, it has become a valuable opportunity to apply the knowledge I've gained about clean architecture and the application of some concepts of what is Domain-Driven Design (DDD).

The project has been organized into three main layers: Domain, Application, and Infrastructure, and possibly the Presentation layer in the future.

Domain Layer

In the domain layer, I've focused on four key aspects:

Value Objects: They represent immutable and fundamental concepts in the application's domain.

Entities: These are objects that have a unique identity and can change over time.

Commands and Their Validators: Handling the actions that can be performed in the domain and their associated validation rules.

Aggregates: Structures that encapsulate multiple value objects and entities.

I've also considered the design of interfaces for future repositories and the handling of domain layer-specific exceptions. However, I'm evaluating whether information related to repository interfaces and commands along with their validators should be placed in the application layer. Time and experience will guide me in this decision.

You can find the repository for the domain layer at the following link, where I've achieved 100% unit test coverage:

https://github.com/ProfeJulianLasso/todo-backend-domain

Structure

The following is the current structure of the domain layer.



📦src

 ┣ 📂aggregates

 ┃ ┣ 📂base

 ┃ ┃ ┣ 📜aggregate.base.ts

 ┃ ┃ ┗ 📜index.ts

 ┃ ┣ 📜index.ts

 ┃ ┣ 📜security.aggregate.ts

 ┃ ┗ 📜to-do.aggregate.ts

 ┣ 📂common

 ┃ ┣ 📂enums

 ┃ ┃ ┗ 📜.gitkeep

 ┃ ┣ 📂exceptions

 ┃ ┃ ┣ 📜domain.exception.ts

 ┃ ┃ ┗ 📜index.ts

 ┃ ┣ 📂interfaces

 ┃ ┃ ┣ 📜complete-to-do.interface.ts

 ┃ ┃ ┣ 📜create-to-do.interface.ts

 ┃ ┃ ┣ 📜create-user.interface.ts

 ┃ ┃ ┣ 📜index.ts

 ┃ ┃ ┣ 📜to-do.interface.ts

 ┃ ┃ ┣ 📜user.interface.ts

 ┃ ┃ ┗ 📜value-object-exception.interface.ts

 ┃ ┗ 📜index.ts

 ┣ 📂entities

 ┃ ┣ 📜index.ts

 ┃ ┣ 📜to-do.entity.ts

 ┃ ┗ 📜user.entity.ts

 ┣ 📂services

 ┃ ┗ 📜.gitkeep

 ┣ 📂value-objects

 ┃ ┣ 📂base

 ┃ ┃ ┣ 📜boolean-value-object.base.ts

 ┃ ┃ ┣ 📜config-value-object.base.ts

 ┃ ┃ ┣ 📜id-value-object.base.ts

 ┃ ┃ ┣ 📜index.ts

 ┃ ┃ ┣ 📜string-value-object.base.ts

 ┃ ┃ ┗ 📜value-object.base.ts

 ┃ ┣ 📜completed.value-object.ts

 ┃ ┣ 📜index.ts

 ┃ ┣ 📜status.value-object.ts

 ┃ ┣ 📜to-do-description.value-object.ts

 ┃ ┣ 📜to-do-id.value-object.ts

 ┃ ┣ 📜to-do-title.value-object.ts

 ┃ ┣ 📜user-email.value-object.ts

 ┃ ┣ 📜user-id.value-object.ts

 ┃ ┣ 📜user-name.value-object.ts

 ┃ ┗ 📜user-password.value-object.ts

 ┗ 📜index.ts

Diagrams

If for some reason you do not wish to review the code, here are the modeling diagrams of the most relevant sections.

Aggregates

Entities

Value Objects

Final words

I appreciate any questions, doubts, concerns, or contributions you may want to make.

I'm completely open to receiving any type of feedback. Please don't hesitate to contact me; I'll be delighted to receive your comments.

Update September 23, 2023

Commands and their validations are passed to the application layer.

Arquitectura limpia (capa de dominio)

Julian Lasso 🇨🇴 — Tue, 19 Sep 2023 16:54:11 +0000

En esta publicación, quiero compartir mi enfoque en el desarrollo de la capa de dominio, aplicando los principios que he aprendido del libro "Arquitectura Limpia" de Robert C. Martin, así como algunos conceptos extraídos de "Domain-Driven Design Distilled" de Vaughn Vernon.

Arquitectura Limpia	Domain-Driven Design Distilled

Para dicha capa he usado mi pequeño boilerplate el cuál puedes encontrar en la siguiente dirección si quieres darle un vistazo: https://dev.to/julianlasso/boilerplate-para-typescript-jm3

¿De qué se trata todo esto?

Mi proyecto actual consiste en desarrollar una aplicación To-Do con autenticación de usuarios. A pesar de ser una tarea aparentemente sencilla, se ha convertido en una oportunidad valiosa para aplicar los conocimientos que he adquirido sobre arquitectura limpia y la aplicación de algunos conceptos de lo que es Diseño Impulsado por el Dominio (DDD).

El proyecto se ha organizado en tres capas principales: Dominio, Aplicación e Infraestructura, y posiblemente la capa de Presentación en el futuro.

La capa de dominio

En la capa de dominio, me he enfocado en cuatro aspectos clave:

Objetos de Valor: Representan conceptos inmutables y fundamentales en el dominio de la aplicación.

Entidades: Son objetos que poseen una identidad única y pueden cambiar con el tiempo.

Agregadores: Estructuras que encapsulan múltiples objetos de valor y entidades.

También he considerado el diseño de interfaces para futuros repositorios y el manejo de excepciones específicas de la capa de dominio. Sin embargo, estoy evaluando si la información relacionada con interfaces de repositorios y los comandos junto a sus validadores debería ubicarse en la capa de aplicación. El tiempo y la experiencia me guiarán en esta decisión.

Puedes encontrar el repositorio de la capa de dominio en el siguiente enlace, donde he logrado una cobertura del 100% en pruebas unitarias:

https://github.com/ProfeJulianLasso/todo-backend-domain

Estructura

Lo siguiente es la estructura actual de la capa de dominio

📦src
 ┣ 📂aggregates
 ┃ ┣ 📂base
 ┃ ┃ ┣ 📜aggregate.base.ts
 ┃ ┃ ┗ 📜index.ts
 ┃ ┣ 📜index.ts
 ┃ ┣ 📜security.aggregate.ts
 ┃ ┗ 📜to-do.aggregate.ts
 ┣ 📂common
 ┃ ┣ 📂enums
 ┃ ┃ ┗ 📜.gitkeep
 ┃ ┣ 📂exceptions
 ┃ ┃ ┣ 📜domain.exception.ts
 ┃ ┃ ┗ 📜index.ts
 ┃ ┣ 📂interfaces
 ┃ ┃ ┣ 📜complete-to-do.interface.ts
 ┃ ┃ ┣ 📜create-to-do.interface.ts
 ┃ ┃ ┣ 📜create-user.interface.ts
 ┃ ┃ ┣ 📜index.ts
 ┃ ┃ ┣ 📜to-do.interface.ts
 ┃ ┃ ┣ 📜user.interface.ts
 ┃ ┃ ┗ 📜value-object-exception.interface.ts
 ┃ ┗ 📜index.ts
 ┣ 📂entities
 ┃ ┣ 📜index.ts
 ┃ ┣ 📜to-do.entity.ts
 ┃ ┗ 📜user.entity.ts
 ┣ 📂services
 ┃ ┗ 📜.gitkeep
 ┣ 📂value-objects
 ┃ ┣ 📂base
 ┃ ┃ ┣ 📜boolean-value-object.base.ts
 ┃ ┃ ┣ 📜config-value-object.base.ts
 ┃ ┃ ┣ 📜id-value-object.base.ts
 ┃ ┃ ┣ 📜index.ts
 ┃ ┃ ┣ 📜string-value-object.base.ts
 ┃ ┃ ┗ 📜value-object.base.ts
 ┃ ┣ 📜completed.value-object.ts
 ┃ ┣ 📜index.ts
 ┃ ┣ 📜status.value-object.ts
 ┃ ┣ 📜to-do-description.value-object.ts
 ┃ ┣ 📜to-do-id.value-object.ts
 ┃ ┣ 📜to-do-title.value-object.ts
 ┃ ┣ 📜user-email.value-object.ts
 ┃ ┣ 📜user-id.value-object.ts
 ┃ ┣ 📜user-name.value-object.ts
 ┃ ┗ 📜user-password.value-object.ts
 ┗ 📜index.ts

Diagramas

Sí por alguna razón no deseas revisar el código, aquí te dejo los diagramas de modelado de los apartados más relevantes.

Agregados

Entidades

Objetos de Valor

Palabras finales

Agradezco cualquier duda, pregunta, inquietud o aporte que desees realizar.

Estoy totalmente abierto a recibir cualquier tipo de retroalimentación. No dudes en contactarme, estaré encantado de recibir tus comentarios.

Actualización 26 de septiembre 2023

Los comandos y sus validaciones pasan a la capa de aplicación

TypeScript Boilerplate

Julian Lasso 🇨🇴 — Sun, 17 Sep 2023 13:45:19 +0000

I present this initial entry both as a resource for my future self and as a source of interest for those who share my passion.

I have created a specific repository with the purpose of establishing a solid foundation from which to start projects using TypeScript from scratch, focused on server-side development (backend).

The repository in question is hosted at the following address:

https://github.com/ProfeJulianLasso/boilerplate-project-typescript

What does this boilerplate offer?

The focus of this project covers four fundamental aspects:

Unit Testing with Jest: The ability to perform unit tests using the powerful Jest tool has been incorporated.

Static Code Analysis with ESLint: The code undergoes rigorous static analysis through ESLint to ensure its quality and compliance with standards.

Commit Management with Conventional Commits: The Conventional Commits methodology is adopted to maintain a clear and structured record of changes with the help of commitlint.

Code Formatting with Prettier: The code is automatically formatted with Prettier, ensuring consistency in writing style.

In addition to these aspects, the repository makes use of Husky to automate certain tasks when making commits and pushing to the repository.

I invite everyone interested to collaborate on this project, and I would greatly appreciate any comments or observations you can provide.

This is a valuable resource for both those who want to start projects with TypeScript from scratch and those looking to improve their skills in server-side development. I am proud to share this contribution with the community, hoping that it will be beneficial for other professionals and technology enthusiasts.

Boilerplate para TypeScript

Julian Lasso 🇨🇴 — Sat, 16 Sep 2023 19:37:43 +0000

Esta primera entrada la presento tanto como un recurso para mi yo el futuro y como una fuente de interés para aquellos que compartan mi pasión.

He creado un repositorio específico con el propósito de establecer una base sólida desde la cual iniciar proyectos utilizando TypeScript desde cero, orientados al desarrollo del lado del servidor (backend).

El repositorio en cuestión se encuentra alojado en la siguiente dirección:

https://github.com/ProfeJulianLasso/boilerplate-project-typescript

¿Qué ofrece este boilerplate?

El enfoque de este proyecto abarca cuatro aspectos fundamentales:

Pruebas unitarias con Jest: Se ha incorporado la capacidad de realizar pruebas unitarias utilizando la potente herramienta Jest.

Análisis estático del código con ESLint: El código se somete a un riguroso análisis estático a través de ESLint para garantizar su calidad y cumplimiento de estándares.

Gestión de commits bajo Conventional Commits: Se adopta la metodología de Conventional Commits para mantener un registro de los cambios de manera clara y estructurada con la ayuda de commitlint.

Formateo del código con Prettier: El código se formatea automáticamente con Prettier, asegurando coherencia en el estilo de escritura.

Además de estos aspectos, el repositorio hace uso de Husky para automatizar ciertas tareas al realizar commits y push al repositorio.

Invito a todos los interesados a colaborar en este proyecto y agradecería mucho cualquier comentario u observación que me puedan ofrecer.

Este es un recurso valioso tanto para aquellos que desean iniciar proyectos con TypeScript desde cero como para quienes buscan mejorar sus habilidades en el desarrollo del lado del servidor. Me enorgullece compartir esta contribución con la comunidad, bajo la esperanza de que resulte beneficioso para otros profesionales y entusiastas de la tecnología.