DEV Community: Paweł

Anemic Model vs Rich model

Paweł — Sat, 17 Feb 2024 14:14:02 +0000

Anemic Model

Someday I fall into a trap and use this anemic model where I should not.

I know that hiding implementation is important.
Therefore the anemic model which has all properties available by getters and setters is not a good solution, because any programmer can call any setter and change the state of the object. Such a Class does not have any business logic, all logic is in other classes like Services or Helpers (therefore named "anemic").

Stability

It is effortless and you may ask why this is a problem.

Let's say you need to set variable is available when some condition is true (e.g. stockQuantity > 50)
If you used this setter you need to write code like this

public function changeAvaiblity() {
if (stockQuantity > 50) {
    $product->setAvaible(true);
}
...
// Product class
public function setAvaibility(bool $avaible): void {
   $this->avaible = $avaible;
}

but how do you ensure that this condition will be covered in another part of the system?

Maybe some programmers did not go too deep and hack your solution

...
$product_service->changeAvaiblity();
...
$product->setAvaibility(true);

As you see setters can be run at any time and change state.

Better solution

So I avoid setting via public setter but I use a private method. But there is a catch here.

Imagine I will get new business requirements, there I wrote a new function but forgot to call the function setAvaibility(true) and my state of the object is not correct.

Use the constructor to set an initial state

The best solution is to use a constructor to set the initial state and simply to avoid to situation where the state of the object is not correct.

Rich domain model

This action is a part of the Rich domain model where we create our models to avoid creating objects in incorrect states.

The purpose of the rich domain model is to create consistent classes, all variables and public interfaces of the class are consistent, and present domain logic.

To archive that, we can use e.g. Value Objects which can guard our rules.

We expose business logic methods not states of objects.
So we use


public function isAvailableForSale(): bool {
if (stockQuantity > MINIMUM_STOCK_VALUE) {
    $product->avaible = true;
}

return $this->avaible;

In the Rich domain model, we expose behaviors. For my little example, behavior is 'Is Product available for sale' but this could be any other question

There is one more point for using rich domain models.
Testing the Rich domain model is much easier than testing the Amenic model.

When we use the Anemic model

We use them as DTOs (Data Transfer Objects) because we want only to read data and send it through e.g. in RestApi, or to send data between layers of our application or for Database entities.

Conclusion

If you need simply DTO, you can create The Anemic model.
But if there is more logic and it is not a simple CRUD you should use The Rich domain model to lean your logic on stable behaviors/contracts which are easy to test and help you to avoid introducing your objects in an incorrect state and make logic and application more consistent.

Be lazy and use Tools (ECS and PHPstan).

Paweł — Thu, 08 Feb 2024 22:36:15 +0000

Be lazy

Be lazy and use Tools, I heard this earlier and totally agree.

They save you time.

Easy coding standard

https://github.com/easy-coding-standard/easy-coding-standard

This tool helps you to keep your code consistent.

The best thing is to get one of the predefined sets and use it in your project, If you want to exclude or add some rules then it is easy to do in your ecs.php file.

The code below uses PRS-12 and excludes Yoda Style (which I personally don't like :) ) and adds some useful Rules e.g. remove unused imports from files.

<?php

declare(strict_types=1);

use PhpCsFixer\Fixer\ControlStructure\YodaStyleFixer;
use PhpCsFixer\Fixer\Import\NoUnusedImportsFixer;
use PhpCsFixer\Fixer\Import\OrderedImportsFixer;
use PhpCsFixer\Fixer\Import\SingleLineAfterImportsFixer;
use Symplify\EasyCodingStandard\Config\ECSConfig;

return ECSConfig::configure()
    ->withPaths([
        __DIR__ . '/config',
        __DIR__ . '/public',
        __DIR__ . '/src',
    ])
    ->withRules([
        NoUnusedImportsFixer::class,
        OrderedImportsFixer::class,
        SingleLineAfterImportsFixer::class,
    ])
    ->withSkip([
        YodaStyleFixer::class,
    ])
    ->withPhpCsFixerSets(
        psr12: true,
    );

You can add as a script to the composer and add to the pipeline to ensure that all members of the team will keep code with standards, that are set in the project.

PHPStan

https://phpstan.org/user-guide/getting-started

This tool helps you to avoid some bugs or make the code more clean.

The command is run by

vendor/bin/phpstan analyse [options] [<paths>...]

You can improve your code step by step because we start from the default 0 level and we can validate the project to max level (9)

I recommend using phpstan.neon.dist in your repository (default configuration).

If you want you can override it by phpstan.neon and add their own rules (e.g. change level).

includes:
    - phpstan.neon.dist
parameters:
    level: 4

Baseline and ignoring errors, exclude paths

You can start using it in legacy code because you can
ignore specific errors, and generate a baseline, which will ignore all errors, that you now have in the project. You can fix it later, but at the beginning concentrate only on new code in the project. You can exclude also some directories or classes.

Nice feature in the config

I like an option to set a clickable link in the code editor after running phpstan

e.g. for PHPStorm (for local)

parameters:
    editorUrl: 'vscode://file/%%file%%:%%line%%'

For more look at the documentation, there are still some interesting things.

Briefly about Clean Architecture

Paweł — Mon, 15 Jan 2024 19:29:22 +0000

Image is worth more than 1000 words

The image above can tell you everything, but below is small description.

About Clean Architecture

It is a principle that has been propagated by Robert C. Martin (a.k.a Uncle Bob) to mix other architecture such as:
- Hexagonal Architecture (a.k.a Port and Adapters)
- Onion Architecture
- Screaming Architecture
- Data, context, and interaction Architecture (DCI)
- Boundary Control Entity Architecture ( BCE )

As Uncle Bob found out, all these architectures are similar and have separations. They are divided by software layers and each architecture has a layer for business logic and interfaces.
Therefore this architecture produces systems that are:

Independent of Framework. The architecture does not depend on the existence of some library of feature laden software. This allows you to use such frameworks as tools, rather than having to cram your system into their limited constraints.
Testable. The business rules can be tested without the UI, Database, Web Server, or any other external element.

Independent of UI. The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules.

Independent of Database. You can swap out Oracle or SQL Server, for Mongo, BigTable, CouchDB, or something else. Your business rules are not bound to the database.

Independent of any external agency. In fact your business rules simply don’t know anything at all about the outside world.
These all are very nice advantages to use this architecture.

The Dependency Rule

This rule says that source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about something in an outer circle

Entities

Entities encapsulate Enterprise wide business rules.

Entities are the business objects of the application. They encapsulate the most general and high-level rules.
They are the least likely to change when something external changes. For example, you would not expect these objects to be affected by a change to page navigation, or security.

Use Cases

The software in this layer contains application specific business rules.

These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their enterprise wide business rules to achieve the goals of the use case.

We do not expect changes in this layer to affect the entities.
We also do not expect this layer to be affected by changes to externalities such as the database, the UI, or any of the common frameworks.
This layer is isolated from such concerns.

Interface Adapters

The software in this layer is a set of adapters that convert data from the format most convenient for the use cases and entities, to the format most convenient for some external agency such as the Database or the Web.

Presenters, Views, and Gateways (Repositories) are here. Data are converted in this layer and pushed back and forth through use cases and entities.

In this layer, you need to expect Adapters :)

Frameworks and Drivers.

The outermost layer is generally composed of frameworks and tools such as the Database, the Web Framework, etc.
Generally you don’t write much code in this layer other than glue code that communicates to the next circle inwards.

Only Four Circles?

No, the circles are schematic. You may find that you need more than just these four.
However, The Dependency Rule always applies.

Crossing boundaries.

We use the Dependency Inversion principle
If your Presenter wants to use a Use case, he needs to use an interface to call it.

Use Case Output => interactor => Use case input

What data crosses the boundaries?

Use simple data structures as Data Transfer Objects (DTO) to transfer data through the layers.
You use it instead of the Resulting Data structure from Database (ResultQuery)

Uncle Bob's Conclusion

Conclusion

Conforming to these simple rules is not hard, and will save you a lot of headaches going forward.

By separating the software into layers, and conforming to The Dependency Rule, you will create a system that is intrinsically testable, with all the benefits that implies.

When any of the external parts of the system become obsolete, like the database, or the web framework, you can replace those obsolete elements with a minimum of fuss.

My Experience without Clean Architecture

I still gather my experience in this architecture, however, I have written some features in this architecture.
I remember when we established a common interface between domains. Me and my team colleague wrote this code and it worked as we expected.
Some refactoring was needed because, as we found out later, we should use the same use case, the base of logic was stable and separated behind a stable interface.
Which helps us even if we don't know too many details about the partner's code.

Improve yourself as a programmer

Paweł — Sat, 06 Jan 2024 17:05:20 +0000

Sometimes we are stuck. Therefore it is nice to have peoples which pushes us in the right direction. This weekend one of them sent me a video https://www.youtube.com/watch?v=q-_ezD9Swz4.

This is what I have learned from this.

Learn how to learn.

As programmers we need to learn a lot, however, if you have your formula it's much simpler and more effective. I heard that

WE REMEMBER

10% of what we read
20% of what we hear
30% of what we see
50% of what we see and hear
70% of what we discuss with others
80% of what we personally experience
95% of what we teach others

Edgar Dale

Of course, there is a Feynman's method, but I still working to implement this in my circle of learning.

Why learning is important

rapidly changing technologies
code is a tool for your customer, it needs to solve the problem
adaptability, sometimes you are not in control, you need to adapt your knowledge to the situation and learn fast to fill the gap.
independent learning, not everything is in documentation, by practice we discover many useful things, but it takes time.
productivity, if you are more efficient in learning then you have more time for other activities, therefore is good to be efficient.

Your Motivation

What excites you and why you code are the proper questions.
You need to know whether you want to code because of your career or you want to write an app or it is simply your hobby. But I think it is nice to have some fun or a strict reason to do this, because when problems appears then you can fall back on your motivation, without asking yourself (x100)

Why do I do this?

Fundamentals are the most important

the author says that you need to use specific technologies when you need to solve specific problems

Web -> HTML/CSS/JS after this you can learn backend
Mobile IOS -> swift
Mobile Android -> Kotlin, Java
Mobile Android and IOS -> ReactNative, Flutter
Video games -> Unity (C#), GODOT (C#), Unreal (C++)
Machine Learning -> python

I agree, however, I think there are other possibilities and if you want to write the game, you can do it in JS, but it will be a game in the browser, so use proper technology for your problem.

Avoiding Tutorial Hell

You need to have a limit to watch tutorials and simply to use the knowledge, which you gather for it.

You need to challenge yourself to solve problems and use the skills that you learned.

This help you

Build Portfolio

The projects that you wrote will speak for themselves.

Code will tell the truth

Circle of Learning

write code (not try to be perfect at first time)
learning
iterating
improving

For me first point it's quite hard. I have many thoughts, I can do this think in this or that way, and waste too much time. Instead of writing a code and measuring the results or simply asking someone with more experience.

Buddy/Mentor or Share your code

If you share your code with others they can give you feedback and your circle of learning speeds up. Same situation if you have a Buddy or Mentor, who can verify your ideas and help you improve your code. Code Review is a good tool that can help us to become better programmers, and many of us like open source projects.

So as the author of the video says

You have to work very hard
and now you know, what you need to work hard.