DEV Community: Ozan Akman

Understanding Domain-Driven Design (Part 1)

Ozan Akman — Sun, 14 Jan 2024 11:48:29 +0000

Introduction

Hey there! Today, I’m explaining a good way of developing enterprise software. I’ve spent roughly 10 years in the industry and experienced many different architectures.

Let me be honest with you, this series won’t be useful if you’re only looking for short-term–rapid application development. I emphasize “short-term” because this is actually faster in the long run. Why? Well, as your product grows to a couple dozen of use cases (if not a hundred), you’ll find yourself fixing a lot of issues. This can slow down your progress in many ways: the release of new features, and bug fixes, onboarding of a new programmer, refactoring, and eventually, creating a bad experience for both you and your users. We’ll explore these issues in detail.

What is “Domain” in Domain-Driven Design?

In Domain-Driven Design (DDD), “domain” means the main area or topic that a software system is about. For instance, Facebook is about the social media domain, while Duolingo is about language and education. It’s the area we want to turn into software. This domain represents the real-world concepts, rules, and processes related to that space. The goal is to understand and model the complexities of that space in software. We want to ensure the software meets the requirements and behaves correctly, according to the domain.

In short, Domain-Driven Design helps you understand your business and users, and create software around their needs. Not influenced by your favorite framework or the preferences of IT people. End-users will never say “Oh look, they’re using the latest JavaScript framework!” unless your target audience consists solely of web developers.

Who is a Domain Expert?

Domain experts are individuals with extensive knowledge in a particular field. In healthcare, these experts could be doctors or nurses. In finance, they might be economists. These experts give useful advice during the software design process. Close collaboration with others helps software developers understand the specific knowledge required to create software, instead of just imagining how things should work. This teamwork ensures that the software aligns with real-world needs and functions optimally. If you’re involved in creating a product for a certain time and making decisions within that area, you too are a domain expert!

Why is Domain-Driven Design Important?

Domain-Driven Design (DDD) is important because it helps people to understand key questions like, “What are we solving?”, “Why are we solving this?”, “Who is this for?”. It helps you to understand that you’re solving people’s problems, not computer problems. By abstracting the domain and using it as the foundation for a software project, we can avoid being tied to specific technical terms, frameworks, or libraries. We can change any other parts of the project, as our foundation — the abstracted domain will remain strong. This means our software reflects real-world situations. We can have a shared understanding between our business and technical teams. This method makes it easier for software architectures to adapt and be modular, letting software systems change as requirements change.

Practical Examples: Design a Blogging Platform with Domain-Driven Design (DDD)

Throughout some examples, you’ll realize that you have more freedom than you might expect, particularly when compared to a framework-centric approach.

We’ll be considering a few different strategies, including Screaming Architecture (also known as Use-case Driven Approach), Test-Driven Development (TDD), and a bit of Command Query Responsibility Segregation (CQRS). Don’t worry if you don’t know these terms, they sound fancy — they’re all tools designed to help solve software design problems.

As for the examples, I’ll be using PHP, which is my language of choice. However, the beauty of DDD is that it’s not about the language or the framework. It’s about designing a software system. So feel free to use any language you’re comfortable with. But before we start, please forget about how you learned to develop software with frameworks. The first thing you will do would be to install a framework because you will need routing, authentication, or validation, right? Not really, you don’t even have one user, yet. First, you need to abstract your domain away. You don’t need any frameworks or libraries other than a testing framework. Something that helps you to prove your use case works as expected.

File Structure

Software design isn’t just about playing with files and folders, arranging them like they’re puzzle pieces. Many developers get stuck in the habit of thinking that designing software is all about arranging files in a certain pattern. What about frameworks? They’re very flexible but they still force their own semantics. They provide a predefined structure, rules, and many different tools, no questions asked, whether you’re building a big blogging platform or a calculator app.

We’re not jumping into picking a framework right off the bat. Sure, it’s convenient to have folders like App/Models, App/Controllers, or App/Events for your small projects. It’s like a cozy house where everything has its place. But when it comes to expanding an enterprise-level project with hundreds of use cases, this cozy house rapidly turns into a complex maze. Can you imagine a newcomer trying to navigate through this labyrinth? The confusion would lead to endless questions and slow progress.

So, instead of starting with a framework, we’ll take a different route. We’ll start by defining our domain model and Bounded Contexts.

Bounded Context: The Building Blocks

When we talk about Domain-Driven Design (DDD), we use the term “Bounded Context” to describe different modules of our software system. Each Bounded Context is unique, focusing on its own tasks, rules, responsibilities, and concepts.

Let’s consider designing a blogging platform. What are the main components? You might think of elements like the blog posts, the authors, comments, and social interactions such as giving a like or dislike. Each of these elements addresses specific aspects. Let’s inspect each one more closely and give them specific names.

Content Management: This context manages all the content-related entities such as Blog Posts and Tags.
Comment: This context handles all entities related to comments, such as Comments, Comment Replies, and Comment Feedback (Likes and Dislikes).
Author Profile: This context manages the Author profile page (Bio, profile picture, etc.), and Followers.
Social Interaction: This context covers interactions such as Bookmarking, Post Feedback (Likes and Dislikes), and Subscriptions (Follow and Unfollow).
User Management: This context takes care of user-related entities such as Settings, Privacy, Notifications, and Premium Subscription.

A couple of Insights

Something is interesting, the User represents the same person, but we treat them differently in different Bounded Contexts. Why is that?

In the User Management context, a User can modify their personal settings, adjust privacy preferences, and manage notification settings.
In the Content Management context, the same User is represented as an Author who creates, edits or deletes blog posts.
On the other hand, in the Social Interaction context, a User might be someone who bookmarks posts, likes posts or follows other authors.

These actors may even share the same name, but they are three distinct actors, each with their own attributes, relationships, and rules within their respective contexts.

Visualizing Bounded Contexts: Project Structure

One major change we’re making is reconsidering how we organize files and folders. Traditionally, developers have followed specific patterns for arranging them, which is largely dictated by the chosen framework. This approach is not the way for every software project. As we’ve discussed, Domain-Driven Design (DDD) focuses on the purpose of the software, which means our file structure needs to reflect our domain model, not the other way around. So, how do we translate the idea of Bounded Contexts into a practical file structure?

Let’s begin by creating a separate folder for each Bounded Context in our blogging platform. These folders will serve as the individual homes for each context’s unique rules, tasks, and concepts.

└── src
    ├── AuthorProfile
    ├── Comment
    ├── ContentManagement
    |   ├── Post.php
    |   ├── PostRepository.php
    ├── SocialInteraction
    └── UserManagement

Here, each folder represents a Bounded Context. Even from this high-level view, you can understand the domain of this application without needing to dive deep into the codebase. This is the essence of Screaming Architecture. So, rather than screaming “This is a Laravel app!”, it screams “This is a blogging platform!”.

But hold on, what about routing? Don’t we need a framework or library for that? Let’s take a step back and remember that we are still in the process of defining our domain and use cases. We are not serving any users, yet.

DDD Layers: Domain, Application, Infrastructure

In the DDD world, usually, the applications are layered into the domain, the application, the infrastructure, and perhaps the presentation. We’ve already discussed the domain layer—it’s the heart of our software, encapsulating the business rules and entities.

The application layer is like the conductor of our software orchestra; it uses the building blocks provided by the domain layer to accomplish specific tasks. Consider a task like PlayMusic, the application layer coordinates the domain objects like Music or Artist to execute this task, guiding the process from start to finish.

The infrastructure layer, on the other hand, is like the stage where our software orchestra performs. It provides the instruments required by the domain and application layers to function effectively. It supports the performance without dictating the music.

The presentation layer is where you perform your gig. It's the concert hall.

Imagine a scenario where your orchestra is restricted to playing in only one place—a stage where you can't move or replace a chair or an instrument. That’s what it feels like when you start your project by choosing a framework. You’re tied to that stage, and any attempt to change a component could break the whole setup. Instead, you should be able to replace infrastructural components at any time without causing a catastrophic failure.

Now, let’s address a common misconception: while these layers are key to designing your software, they don’t necessarily need to directly translate into your folder structure.

└── UserManagement
    ├── Application
    ├── Domain
    └── Infrastructure

Many developers, myself included, have understood these layers as something to be explicitly represented in the codebase, resulting in folder structures like the one above. While this structure is often more manageable than a purely framework-based one or the traditional MVC folders, it still misses the point: DDD is not about folder structures, it’s about software design. The layers should guide your software design as a principle in your mind; it doesn’t have to be a literal representation in your folders. Simply put, you should have a clear mental picture of this layered architecture; it doesn’t have to be exactly reflected in a folder structure.

Now, let’s take a moment to consider the folder structures above – whether you’re an experienced developer or not, think about which one truly makes it easier to maintain the code?

Our First Use Case: Creating a Blog Post

The first step in designing our blogging platform using Domain-Driven Design (DDD) is to focus on the use cases. Before we dive into routing, logging, or caching, let’s remember that these are infrastructural concerns and can be easily replaced. We shouldn’t be bound to specific tools; after all, tools are meant to assist us in achieving our goals.

Let’s start by learning the blueprint of our application. The journey begins from a Bounded Context and then drills down into specific use cases. You have the option to create additional folders to separate sub-contexts, like src/ContentManagement/Post/CreatePost, instead of src/ContentManagement/CreatePost. That’s totally fine! The key here is ensuring the folder structure is easy to understand and makes sense to anyone who looks at the codebase. It should focus on the domain logic rather than being overly technical or grouped by file types. We want it to be clear and straightforward so that developers can quickly grasp how everything is organized. With this approach, we can gain a clearer view of our initial design before refining it further.

└──📁src
    └──📁Bounded Context
        ├──📁Use Case 1
        ├──📁Use Case 2
        ├──📄Context Object 1 (e.g. Domain Entity)
        ├──📄Context Object 2 (e.g. Repository Interface)
        └──📄Context Object 3 (e.g. Aggregate Root)

# This translates into something like the following in real-world projects.

└──📁src
    └──📁ContentManagement
        ├──📁CreatePost
        |     ├──📄CreatePost.php
        |     ├──📄PostCreated.php
        ├──📁GetPost
        ├──📄Author.php
        ├──📄Post.php
        ├──📄PublishedPosts.php
        ├──📄PostRepository.php
        └──📄PostRepositoryUsingDoctrine.php

Conclusion

Great job finishing Part 1! We’ve learned important concepts like Domain, and Bounded Context. Let me know what you think in the comments! I hope to publish every week, on Sunday. In the next part, I'm aiming to provide more examples and practical use cases. I want to ensure everything is easy to understand.

If you enjoyed this article, let’s connect on https://twitter.com/akmandev and https://www.linkedin.com/in/ozanakman for more content like this!

Why is it difficult for many people to create things consistently?

Ozan Akman — Sat, 06 Jan 2024 17:43:43 +0000

Hey there, today is not about tech talk. I've been thinking about some drafts that have been sitting around untouched for a while. I asked ChatGPT why it's so challenging to create things consistently, but its responses were quite basic, as usual. The question I'm trying to answer is, “Why is it difficult for many people to create things consistently?”.

Anyway, I just figured it out, it's difficult because it's not fun. It's not engaging at all. Staring at a blank screen and trying to put thoughts into words? Not the most thrilling activity. Expressing what's in your head? Tough stuff. Even experts struggle to explain what they know. Not only that, doing consistent open-source work, or developing your side project in your free time. All of that is difficult.

It's not just difficult; it's made even more difficult by the complexities of modern life, and all the distractions like social media, Netflix, or video games. Imagine, you have a family with kids. Just thinking about it can be overwhelming, let alone finding the focus. But you know what? Some folks still manage it. How? Well…

How do other people do it?

I'll tell you straight ahead. The people I know, they don't really care if something's boring or exciting—they push through regardless. They have control over themselves, and their mind. They look from the perspective, “Okay, this needs to be done”. Sounds easy, but it isn't. This requires discipline. Being able to concentrate, even when you'd rather be doing something else, is an amazing skill. It's kind of what meditation practices teach. So how do you improve that skill?

How can you focus on boring tasks?

Our knowledge about our brains today is quite remarkable. I'm not an expert in that area, but I've been diving into neuroscience and the human body lately. Essentially, you've got to train your brain for this. It would help if you learn how to relax and how to lower your stress level, so you have space for other things. I'm pretty sure, you had those days when you stressed yourself with something, out of nowhere. Well, guess what? You can do the exact opposite. You just need to learn how. If you're interested in this topic, I would recommend Wim Hof's breathing technique, it's amazing. I would also suggest listening to a podcast or watching a clip from people like Andrew Huberman. Meditation is another great tool. Sitting there in a stance, and focusing on yourself, telling your mind what to do. It seems boring at first, but it's insanely effective. That's why meditation practices have been passed down through generations. Because it works! The cold showers are fantastic. There are tons of scientific evidence behind it. So, if you're curious, dive into all this stuff, especially on YouTube if videos are more your thing!

Oh, by the way, our brains aren't the only important bits in our bodies, everything is connected. So, taking care of your whole body is crucial for your brain to perform at its peak. We have a proverb in Turkish that goes something like “A healthy mind in a healthy body”. Exercise regularly, maintain a healthy diet, and ensure good sleep. Don't try to cheat on your body. What are you trying to save? Time or money? At the expense of your own well-being? Take the time to prepare a wholesome meal. Understand your body and its needs.

Understand yourself

Creating regularly can be tough, no doubt about it. But remember, every small step counts. Embracing the challenge and staying disciplined, even when it feels hard, leads to wonderful growth. Understand, and don't be so hard on yourself. Be flexible when you need to. Learn how to love the process, not only the outcome. The struggle today becomes the strength tomorrow. If you improve by 1% every week for a year, you will be approximately 164.7% better by the end of the year compared to where you started. You've got this!

Stay connected

Thank you for reading! If you enjoyed this article, consider following me on https://twitter.com/akmandev and https://www.linkedin.com/in/ozanakman for more content like this. I'm trying to regularly share insights on software engineering that can help you improve your skills and stay up-to-date with the latest trends in the industry. I appreciate your support and hope to connect with you soon!

Building Beyond Tools: What’s Wrong with Modern Framework-based Development?

Ozan Akman — Sat, 13 May 2023 09:24:28 +0000

The Road to True Expertise: More Than Just Tools

In modern programming, languages and tools have made it easier than ever to code. You can create a web project without spending four to six years buried in textbooks and lectures. I believe I could teach anyone the basics of web programming in just six short months. However, don't mistake a quick education for mastery. True expertise is earned through years of work, endless failures, and a constant thirst for knowledge. It takes years of practice, study, and engagement with the broader community to truly become an expert in our field. Have you ever tried to explain a difficult concept to an inexperienced developer? Described a solution to a complex problem? Lead group of developers? Documented your code in a way that empowers your colleagues to build on your work? Simply spending time in the industry or having a successful Youtube channel doesn't make you an expert. True expertise comes from deep knowledge and the ability to communicate effectively.

People who are intelligent and experts in their field, tend to question everything with an open mind and come up with logical reasoning. People who are inexperienced or lack knowledge often have strong opinions and beliefs and are not open to new ideas or ways of thinking. Approach problem-solving with an open mind, question assumptions, and follow the evidence. This is what leads to success in any field, not just intelligence or experience alone.

Don't Start Your Project by Picking a Framework

As software developers, we are constantly bombarded with new and exciting tools that promise to make our lives easier. While frameworks can be useful tools, they can also lead us down the path of technical debt if we're not careful. The problem with frameworks is that they come with a lot of assumptions about how your application should be structured and what features it should have.

Write code around the core of your business idea, also known as business logic, rather than around the tools. Let's say you're working on an e-commerce project. Your first concerns should be related to product pricing, inventory management, order processing, and shopping cart. You don't need to worry about user authentication, authorization, or email sending at this stage. By building your foundation around your business logic, you can choose whatever tool or framework you prefer for the infrastructure or UI layer concerns.

Another example is a social media application, where your focus should be on user profiles, messaging, and content moderation, without concerning yourself with error reporting or caching. Understanding this concept will help you see tools as replaceable parts of your project. It's important to keep in mind that framework creators tend to market their products as must-have tools, and their documentation and tutorials often emphasize using their specific tools for project creation. But with a solid understanding of business logic and the needs of your application, you can choose the right tools to support your project and bring it to life.

That's where abstraction comes in. Abstraction is the art of simplification - of breaking down complex systems into simpler, more manageable parts. By abstracting away the details of your application's implementation, you can create a more flexible, adaptable architecture that can evolve over time. When we build our application around a framework, we are essentially taking away this flexibility and building on a set of technical debts that we may not fully understand.

Rapid Application Development Doesn't Solve All Your Problems

Rapid application development is encouraged in some communities, such as the Laravel community. They show examples of small teams or solo developers making a lot of money. Tempting. However, this doesn't mean they are creating high-quality software. They usually sacrifice good architecture in order to start their business quickly. And, as they're solo developers, I completely understand. It is effective for them. The problem is that they promote this approach as the way to go! Being a good software architect is not the same thing. It's important to remember that simply knowing how to code does not qualify someone as an industry-leading expert. As I previously stated, anyone can learn the basics of web programming in as little as six months.

Some people may think that building an application based on business logic is slower than using specific tools. But, it's not always the case. Although it may take some extra time, to begin with, it makes it easier to maintain the code in the long run. Also, you don't need to hire a specialized developer who knows a specific tool, any good developer can understand and work with your code. This saves time and increases flexibility.

Another benefit of this approach is that the developer will better understand your business. This helps them to contribute better to the project and become a partner in your business's success. Although it may require a little extra work at the beginning, prioritizing business logic over specific tools can have many advantages in the long run.

In the initial stages of a software project, it's crucial to define the problem you're trying to solve and the objectives you aim to achieve with your solution. By asking these fundamental questions, you can shape your architecture effectively. To this end, it's essential to identify your use cases. A use case is a particular scenario or situation in which your software will be used. This technique helps to ensure that your software satisfies the unique needs of your users, thereby enabling you to create high-quality software that meets their expectations.

What's More?

As you are, I am also a learner. Every day, I'm eager to learn what the best approach is. Trying, not to have strong opinions and question everything objectively.

I am planning to create a series of articles with a lot of code examples. Additionally, I will provide a solid open-source project that you can explore to see how those examples fit into a real project. Let's stay connected!

Meanwhile, I suggest you read Screaming Architecture by Robert C. Martin (Uncle Bob).

Thank you for reading! If you enjoyed this article, let me know your opinions in the comments section! You can follow me on https://twitter.com/akmandev and https://www.linkedin.com/in/ozanakman. I'm trying to regularly share insights on software engineering that can help you improve your skills and stay up-to-date with the latest trends in the industry. I appreciate your support and hope to connect with you soon!

Avoid These 5 Mistakes in Your Software Company

Ozan Akman — Wed, 19 Apr 2023 08:51:58 +0000

Throughout my career as a software engineer, I have worked in many different kinds of situations. From small teams to some of the biggest in the industry. The successful ones all had one thing in common: they valued their employees as the cornerstone of their business. In the fast-paced software world, companies might get so focused on delivery that they fail to see their mistakes. We'll go over some typical mistakes I've faced before and wished to change while working at those companies.

1. Not investing in employees

Employees are the backbone of any business. They form the foundation. It is critical for companies to invest in their employees' personal development. Because it is their skills, expertise, and motivation that result in high-quality products. They are an essential part of your company's success. A poorly trained or demotivated workforce, on the other hand, might result in decreased productivity, higher error rates, missed deadlines, and, ultimately, dissatisfied customers. Do not consider your employees as disposable operation units; doing so will lead to the failure of your organization.

2. Not prioritizing automated testing

A lack of expertise can lead to deprioritizing automated testing. The problem is that testing is an essential component of the software development process. Because it doesn't only ensure your product can run smoothly; it also helps identify and resolve issues before they become major problems. Without proper testing, your product will most likely suffer from a range of issues. Unexpected crashes, bugs, errors—you name it. This leads to a negative user experience. Therefore, frustrated users Some critical bugs can even lead to reduced sales or legal issues. Also, without proper testing, you can't refactor your legacy code. I talked about this topic in one of my previous articles.

3. Failing to plan

Planning is a fundamental component of the software development process. It's often overlooked in favor of fast delivery. The pressure to release quickly can lead to rushed coding without sufficient planning, which can result in a range of issues. It can lead to scope creep, poor communication, and, of course, delays. The poor communication results in poor collaboration, and so on. It will drain the limited resources you have, leading to inefficiencies and poor user experiences. Not only that, your employees won't be able to measure their impact and will always feel like they're failing. This will result in employee attrition.

If you're a small company, I would suggest that you not only listen to your managers but also listen to all of your employees.

4. Ignoring feedback

We're going to talk about two different types of feedback: employee feedback and customer feedback.

Employee feedback provides valuable insights into the development process and helps identify improvement areas. If you think you know it all as a manager or fail to take employee feedback seriously, thinking it's unimportant or irrelevant, this will reflect on your company. It will lead to a lack of engagement and motivation among team members. They will feel like their contributions are not valued, so they will contribute the bare minimum. Poor morale, reduced productivity, and high turnover rates result in a costly mistake for your company.

Besides that, ignoring user feedback is also an equally problematic mistake. Disconnecting your product from the needs of its end users can easily lead to a poor user experience and lost sales. You should use user feedback as a guide to the development process.

5. Micromanagement

Micromanagement is an absurd management style where managers closely monitor and control those who report to them. I'm sure many of us have dealt with micromanagement at some point in our careers. This will result in a lack of trust between managers and staff, which will lead to less collaboration and communication. It will affect the quality of deliveries. Employees will be disengaged and demotivated. They will feel a lack of autonomy and control over their work. Eventually, there will be less creativity and innovation.

What actions can you take to avoid micromanagement?
Simple: Trust in your employees. Encourage open communication. Listen to employee feedback and provide feedback back to them regularly. Focus on the outcome. Rather than controlling, provide support and guidance.

Let me conclude this section with a Steve Jobs quote:

The greatest people are self-managing -- they don't need to be managed. Once they know what to do, they'll go figure out how to do it. What they need is a common vision. And that's what leadership is: having a vision; being able to articulate that so the people around you can understand it; and getting a consensus on a common vision.

Stay Connected

Thank you for reading! If you enjoyed this article, consider following me on https://twitter.com/akmandev and https://www.linkedin.com/in/ozanakman for more content like this.

I'm trying to regularly share insights on software engineering that can help you improve your skills and stay up-to-date with the latest trends in the industry. I appreciate your support and hope to connect with you soon!

Refactoring Legacy Applications

Ozan Akman — Sun, 12 Feb 2023 09:08:30 +0000

What's refactoring?

Refactoring is the process of improving the structure of code without changing its behavior. It can increase readability, maintainability, and performance. It can reduce technical debt. When a codebase is cluttered and outdated, there are two options: rewriting the code or refactoring it. While rewriting is easy for developers, it is very expensive. Refactoring can be done without disrupting internal and external processes. This article will guide you through the process of legacy code refactoring and highlight common pitfalls and how to avoid them.

Steps of refactoring a legacy codebase

Understand: To begin, you must understand the current architecture. Take your time learning about its structure and how different parts interact with each other. Are there any patterns? Is there a reason for the complexity?
Identify: Always look for ways to improve. Is it possible to make the code more readable, maintainable, readable, and scalable?
Prioritize: Following your understanding and identification, you can now prioritize the areas that require your focus first. Make a plan to deal with them. Create an Impact Effort matrix (2x2) to understand the potential impact and effort required for each task.
Backup: Even though version control systems are already used by the majority of engineering teams, it's a good idea to keep this in mind. Make sure your application is safely backed up in its most recent stable state before making any modifications. Both the data storage and the codebase.
Test: To ensure that the refactoring has not produced any new bugs or unexpected behavior, validate it with automated tests. Write your tests against desired behavior. If there are existing tests, keep them to validate that the changes have not produced any side effects. The rule is simple: If you can test it, you can refactor it.
Decompose: When broken up into small pieces, it is simpler to handle the refactoring process. You can isolate those parts and have the option to test those smaller components separately. Additionally, breaking things into tiny pieces makes it simpler to evaluate your impact. It's much simpler to understand and document the smaller part.
Document: Start keeping track of the procedure. Document your understanding and any changes you make. Ensure consistency between your refactoring approach and the documentation.
Repeat: Keep repeating the process until all necessary components of the application are improved. Refactoring a legacy app is not a straightforward, one-day task; it requires ongoing planning and execution.

Why would refactoring even be necessary?

Let's imagine! You have a large service called Printer that has numerous dependencies. And it wasn't always this way. The first code was written ten years ago by two college friends. It was intended to print two simple tables. The developers felt there was no need to make it complicated. They decided that they will easily create a simple service to handle those tables. There were two methods in the service: printEmployeesTable() and printDocumentsTable(). Those methods simply converted tables to pdf format. As a result, the first dependency was a service called HtmlToPdfConverter. Fast forward to today, their product is a success story. They've been adding new features and appealing to larger audiences since then. As an outcome, more printing methods were required, such as printSalariesTable(), printTranslationsTable(), and so on.

However, it wasn't that simple. They had to expand the capabilities of the Printer service because their audience was larger. Such as queues, printing in several formats, permission, and much more. You might also assume that the dependencies started growing at the same pace. When new developers joined the team, they just followed the proven procedures. They didn't want to break it. The Printer could print approximately 100 different outputs after ten years of development, each with a corresponding so-called "simple" printing method. The Printer service and the other components are tightly coupled. Even though that service still functions today, it now contains at least 10,000 lines of code and perhaps 20 or even more dependencies. Making changes is a headache because it is not readable anymore. All printing methods are all out of sync and operate in different ways. You cannot just decide to add CSV printing functionality to all tables. It's quite difficult to keep it stable and bug-free. However, this is not the end of it. Your clients want the same print functionality for a feature you're planning to release. The tricky part is that you need another dependency in order to print this new output. What will you do in this situation? Does it make sense to add a dependency and a new method to the Printer? When there are already more than 20 dependencies? Dr. Refactoring, we need your superpowers!

Knowledge to the rescue

As we already know, practically every other component highly depends on the Print service. How can we even take a small piece of it out without affecting the other components?

I'll give you a hint: There is a solution to this problem, and there will always be a solution. For this new feature, you should start with creating a test case. Once you have a failing test case, you can start the decomposition. The decorator pattern, for example, could be useful in that situation. You may make a standalone NewFeaturePrinter and decorate the good old Printer service. You may encapsulate the logic of the NewFeaturePrinter in itself this way. It can be tested in isolation. The old Printer doesn't even need to be changed, and it is unaware of the NewFeaturePrinter. At the very least, it's a much better alternative than adding more complexity to the already-existing Printer. The decorator pattern could also help you in breaking down this large service into smaller ones, more manageable pieces, especially when your components are tightly coupled. Perhaps you can resolve this issue without even using a pattern. The idea is that we should figure out a way to separate it into encapsulated chunks. This description of decomposition is also known as the Extract Method, a well-known refactoring technique.

There are many design patterns and several different techniques. Almost all of them were motivated by a specific problem. Increasing your knowledge could save you and your team a significant amount of time and money. Most businesses are unaware of their technical debt until it is too late. Refactoring should be an ongoing process for legacy applications.

Final thoughts: Keep it simple

Each team is organized differently. Finding one single way to manage this process for all is challenging. However, you can always follow the steps I defined above. Not everything needs to be refactored at once. Begin with renaming. Begin with breaking down complex services into simpler ones. Leverage design patterns. Learn from your own mistakes. Decouple and encapsulate your components. Test in isolation. Progressively get away from the complexity. And repeat.

Symfony is not the best framework.

Ozan Akman — Sun, 29 Jan 2023 08:53:36 +0000

Initially, I wanted to reply to a Reddit comment. It was already long enough to classify as a blog post. I hope you enjoy reading it. Let me know your thought on the comments.

Simply put, Symfony isn't ideal for every situation.

Who am I?

I'm Ozan Akman, an experienced full-stack developer. I've worked with Laravel, Laminas (formerly Zend), and Symfony for many years. I've spent the last five years working for product companies. So, enterprise-level PHP frameworks were always on my radar. Due to my new employment, I shifted to backend development 1.5 years ago. Since that shift, Symfony is what I use. I love it. But must admit that I've seen some terrible Symfony apps. The developers who built a beautiful architecture that is enjoyable to work with are responsible for this "love it" experience, not the framework itself.

There are several requirements, but let's try to figure it out.

What is Symfony best at?

Development speed? Laravel is much faster than Symfony.
Overall development experience? When you get used to it and properly put it up, Symfony is pretty good.
Learning curve? Symfony is not the best choice.
Documentation? Symfony is effective but messy at the same time. It could be improved.
Configuration? Symfony is a fantastic choice.
Dealing with complexity? Symfony is one of my best experiences to solve complicated challenges with ease.

In the end, it all comes down to your goals.

What's the best PHP framework?

Do you have limited resources and need to complete projects quickly? Laravel is a fantastic option. Do you prefer less magic and more stable ground? Symfony is a fantastic option. Will you be handling the client code? or designing an API only? Symfony is a fantastic option. But it couldn't even come closer to Laravel's full-stack capabilities. Testing with both frameworks is a joy Do you really need so much flexibility? Laminas is great and flexible but it makes things harder and DX isn't the best. You deliver slower than other frameworks.

Every framework can scale. Each and every framework has excellent tooling. To be honest, working with nearly any advanced PHP framework is a joy. We have options, which is great.

My personal experience with frameworks

And again, I love Symfony. Two months ago, I started working on weekend projects, and Symfony was my first pick. After a month, I made the decision to try Laravel because I believed I could develop more quickly with it. That was true. I have a nice speed boost thanks to Laravel. You should know that I haven't worked with Laravel in about five years. There were a few tweets and stories that I saw, but that was it. For many years, I lacked first-hand experience. I could change to it so quickly. It was quite surprising. And the combination of Laravel and Inertia is simply amazing. Everything depends on the content and timing of your delivery.

I can also see why Laravel is so hated, especially among experienced developers. It has a feature called Facade that allows you to access objects from a container. I try to avoid using the Facade feature because it feels like too much magic. Of course, you are free to use dependency injection. But Laravel forces you to use its own methods, you're not as remotely free as Symfony's flexibility. It lacked proper type hinting for so long. Unquestionably, there is room for improvement. Laravel isn't the best, but it does the job for a full-stack project with just a solo programmer.

You're the best framework

I intentionally stated that "it is not the best framework" for all of the mentioned frameworks above because none of them is the best. You need to make the most of them.
You need to focus on creating your system using design patterns, having a good architecture (e.g. hexagonal architecture), and around DDD principles.
The next time you choose one of those frameworks, you need to focus on delivery and timing. You need to decide what's the best framework for you.
In the end, there is no such thing as "the best" framework. It all depends on you!

Understanding black-box and white-box testing

Ozan Akman — Sat, 28 Jan 2023 10:57:10 +0000

What is black-box testing?

Black-box testing is a method of software testing that examines the functionality of an application without peering into its internal structures or workings. It is also known as functional testing or behavioral testing. The tester is only concerned with what the application does, not how it does it. The goal of black-box testing is to ensure that the application meets its requirements and behaves as expected for the end user.

Should we test internal parts with functional test cases?

Functional testing, also known as black-box testing, is focused on testing the software application's external behavior and functionality, as seen from the end user's perspective. It is not typically used to test the internal workings or structure of the application.

Internal parts of an application, such as individual modules or components, are typically tested using unit testing, which is a method of testing individual pieces of code in isolation. Developers typically write unit tests to verify that the code they have written is working correctly and meets the requirements.

That being said, it is possible to have functional test cases that test the internal parts of the application by testing the interaction of different internal components, in this case, it's called integration testing. This method of testing ensures that the various parts of the application are working together correctly and that there are no conflicts or issues when they are integrated.

In summary, functional testing is focused on the external behavior and functionality of the application, while unit testing and integration testing are focused on the internal parts of the application.

What are the key differences between black-box and white-box testing?

Black-box testers only have access to the inputs and outputs of the application, and not to the internal code. This method of testing is used to ensure that the application behaves as expected for the end user and meets its requirements.

On the other hand, white-box testers have access to the internal code and design of the application and use this information to test individual pieces of code to ensure that they are working correctly. This method of testing is used to ensure that the application is functioning correctly at the code level and to identify any bugs or issues that may not be visible from the user's perspective.

In summary, the key differences:

Black-box testing is done from the user's perspective, while white-box testing (unit, integration, etc.) is done from the developer's perspective.
Black-box testing does not require access to the internal code, while white-box testing requires access to the internal code.
Black-box testing is focused on testing the external functionality and behavior of the application, while white-box testing is focused on testing the internal code and design.