Domain Models

In this blog post, we’ll dive into the concept of domain models, explore the differences and discuss how these choices impact your software design.

WTH is a Domain Model?
Instead of saying something like "the term domain model refers to an abstraction that represents the real-world concepts and behaviors of a system" i find that stackoverflow reply more helpful:

If you were to take your program and strip away the gui and the DBMS, and replace it with a command line interface, and a MySQL server instance, then port the whole thing to a different platform with different system calls and file system access api calls, the part that you didn't change in that process is the domain model.

Types of Domain Models

Repurposing Android Phone as UMPC

Revisiting project in this post: https://can.kurttekin.com/2020/07/building-cyberdeck-ish-netbook.html

I will be sharing  details and files in my GitHub repo so you can build yourself.
https://github.com/cankurttekin/umpc-phone

 

 

Lenovo Erratic Touchpad Fix

My touchpad felt laggy and jumpy on my Lenovo Yoga 7 after a week i bought it. It starts with finger rubbing and it is not OS related doesnt go away if i dont press to hard on it to make it contact with something on the body and release the static energy. I opened up the laptop and observed the issue and its grounding problem. 

On the left side there is squishy conductor, its almost went deep inside and doesnt make contact with touchpad. I tried poking it with screwdriver to reform to its original shape. This fixed problem but after couple days it looses that squishy form again and problem starts again.  I added aluminium foil to right one, i made a bit thicker where it contacts squishy thing so when touchpad screwed in to place it should contact.

Dependency Injection

When you have different objects and services that does different things and developed by different teams how do you connect them becomes an issue.

DI is a design pattern that aims to decouple object from their dependencies. Instead of creating their own dependencies internally, object receive them from an external source. By using DI we can configure as needed at runtime; with DI dependencies injected at runtime rather than at compiling.

Dependency injection works together perfectly with SOLID principles.
Single Responsibility Principle - DI can help you isolate responsibility of class.
Open-Closed Principle - With new functionalities we can inject new dependencies instead of changing code base.
Dependency Inversion Principle - Dependencies depend on interfaces instead of concrete classes.

There are three types of DI: Constructor Injection, Setter Injection and Interface Injection.

I will give examples as POJO classes, this pattern can be applied to any language and there are solutions in Spring and .NET.

I will build an awesome(?) music lister that lists your musics from particular artist.

How To Secure Your Spring Application

When developing an API for a business, one of the key requirements often revolves around managing different user types and their respective permissions. In this scenario, we'll focus on three user types: admin, individual user, and corporate user.

User Roles Overview:

• Admin: Has all the privileges of the individual and corporate users, plus additional administrative capabilities.
• Individual User: Accesses standard user features.
• Corporate User: Similar to the individual user but may have access to additional resources or features tailored for corporate use.

In this post, we’ll focus on implementing the authentication and authorization mechanisms necessary to enforce these roles, ensuring the system adheres to the statelessness principle of REST.

Understanding Authentication and Authorization

Authentication vs Authorization image from javatpoint.com

 

 

Event Sourcing Pattern

An architectural pattern that models the state changes made by applications as an immutable sequence or “log” of events. Instead of modifying the state of the application in-place.

Generally with crud applications we hold only current state not how we got there. That might be issue for some applications. For example lets think an online banking application. If only thing they can see is current balance not how they got to that balance, no withdrawal, deposit or fee history.

Immutability

Immutability refers to the property of an object or data structure that is can not be modified or changed after it is initialized. Once an object created, its state can not be altered, if there is a need for a change than new object created with those changes and first one will be stay unchanged. This is valuable design choise for data integrity concurreny in multi threaded applications. Immutable objects are useful in scenarios where consistency and predictability are crucial. In some applications you wouldnt want your same data be changed simultaneously by different parts of the application.

Why?
When a data leaves a source, it passes through many different systems, each system uses a point of this data and transfers it to another system. For example, a data coming out of the database gets the first shape on a programming language, then it is kept in the necessary "stacks" and "queues" on various "pipelines", then different "threads" use the data, various "message queues" send the data to "microservices" on servers running in different locations, they use something from the data and the data ends its journey at some point. But during this journey, many different pieces of code compete to process this data, and some access and process this data first, some later.
 
Thats where immutability shines. If this data is not immutable, we will be dealing with possible problems during the entire journey of the data. If the first code runs a few milliseconds late for very different reasons, and the second code handles that data before and deletes the required value, it is possible that we will encounter a problem at that moment.

Onion Architecture

I will try to explain what Onion Architecture is, pros and cons and implementation example.
 

So first of all software architecture's like a blueprint for both the system's behavior and the mechanisms used to achieve that behavior.

Architecture provides structured approach to managing complexity of software systems. It supports scalability, maintainability and flexibility by defining patterns and practices, making it easier to understand, promoting code reuse and adapting to changing requirements.

 

Origins of Onion Architecture

With commonly used traditional layered architecture, each subsequent layer depends on the layers beneath it. This creates thight coupling, makes it challenging to replace, upgrade or adapt changes without affecting all layers. (As Palermo says when explainin this arch.: "However, without coupling, our systems wouldn’t do anything useful, but this architecture creates unnecessary coupling.")

 

 With this architecture, dependency/coupling is towards the center. All code can depend on layers in the center but can not depend on layers further out.

 

Onion Architecture

Number of layers may vary depending of the application but domain model is always at the core. Domain model is not coupled to anything but itself. 

Design Patterns

Design patterns provide tried and tested, optimum solutions to some commonly occuring problems.

Benefits of design patterns:

• Code reusability, as you might heard in object oriented programming concepts, instead of developing something over and over again from scratch, we want to reuse existing one to reduce development costs and time. Design patterns makes reusing easier.

• It makes communication easier by providing a common language on some design details.

For example an app needs a single instance of a class at runtime. if there isn't any instance created then it should be created: if there is, that one should be used instead of creating again etc.

or you could just say we need a Singleton class.

• Robust and effective solutions. As said in the first sentence design patterns are tried and tested solutions they are result of extensive experience.

• Improves code readability. It helps new or less experienced developers learn and adopt quickly.

• It helps your code to be more flexible and extensible.

Ok, we talked about some of the benefits of design patterns and want to learn more about them, so where do we start? Design patterns are divided into four category as Creational, Structural, Behavioral and Concurrency. In this writing, i am gonna try to explain some of them.

DIY Handheld(?) Retro Game Console(from overpriced tablet and cheapest controller)