Let's separate the separation — DeepSeek Blog | Neura Market
    Neura MarketNeura Market/DeepSeek
    ChatGPTChatGPTClaudeClaudeGeminiGeminiCursorCursorGrokGrokPerplexityPerplexityDeepSeekDeepSeek
    CoPilotCoPilotStable DiffusionStable DiffusionMidjourneyMidjourney
    View All Directories
    OverviewRulesPromptsMCPsAgentsBlogVideosGuidesCoursesCommunityTrendingGenerate
    DeepSeekBlogLet's separate the separation
    Back to Blog
    Let's separate the separation
    backend

    Let's separate the separation

    shymi December 31, 2025
    0 views

    It was during the last days of 2025 when our team lead decided to take an extra day off and missed an...

    It was during the last days of 2025 when our team lead decided to take an extra day off and missed an interesting meeting. After a recent restructure, one colleague moved out of the project, and 2 newcomers were added. The topic seemed simple: how should we structure our new code. Architects agreed on a DDD separation with additional grouping of `rest`, `core` and `repository` sub-packages(it is a Spring Boot web project) for each domain. This led to an interesting discussion separated should those three layers should be. During my ~10-ish years of professional career, the most commonly used approach has been having a `DTO` POJOs at the entrance/exit of the `REST` controllers which were transformed to an `entity` objects which corresponded to the structure of the data in the storage used(i.g. RDBMS). Some process exclusive POJOs might exist, but we won't mention them for sake of simplicity. The process would look something like this: ![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/y6x8sj5hnls4eet4jggp.png) The main reason for separating the request/response objects from the ones which were used for storing/extracting data from a storage was that they might have a different structure and even if they are absolutely identical - it is a way to future-proof the code against changes. Strictly speaking, this doesn't fully decouple the `core` and `repository` part of the code - any changes to the `repository` `entity` will directly affect the `core`, but in my experience you don't randomly change the `entity` you use without a need for that from the business logic(`core`) and thus I have formed the habit of only using a DTOs and entities. There was a team decision, despite my disagreement, to fully decouple the `core` from the `repository`, so now we have something like this: ![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2drcs6b5jbyh5385gj8k.png) Although it seems pretty similar, now we have additional mappers and POJOs which are copies of the entities. My main concern was the overcomplication when a change is needed - there are more classes which must be changed, which, with time and project growth, will bring, in my eyes, unnecessary complication. At the meantime it might be useful in the future if there is an optimized structure for the process in the `core` classes which is totally different from the `repository` ones. But hey - I might be wrong here and am afraid of a non-existent problem. Constructive feedback is always welcomed. Godspeed and wish you all fantastic holidays!

    Tags

    backendprogrammingarchitecture

    Comments

    More Blog

    View all
    How I'm using ASTs and Gemini to solve the "Codebase Onboarding" problem 🧠ai

    How I'm using ASTs and Gemini to solve the "Codebase Onboarding" problem 🧠

    Hi everyone! 👋 I’m Tara, a Senior Software Engineer and Consultant. Over the years, I've jumped...

    T
    tworrell
    Local AI Will Save Us All (The Math Says So, Trust Me)ai

    Local AI Will Save Us All (The Math Says So, Trust Me)

    Every few weeks a take goes viral in tech circles making the case for ditching cloud AI and running...

    S
    Sebastian Schürmann
    Lost in the AI Hype, I Started Smallai

    Lost in the AI Hype, I Started Small

    And it helped me get back into tech without drowning TL;DR at the end Coming back to...

    R
    Rohini Gaonkar
    Building a Replay-Tested Interactive Brokers Client in Gogo

    Building a Replay-Tested Interactive Brokers Client in Go

    I wanted an IBKR library that felt like Go and had testing I could trust. So I wrote one.

    T
    Thomas Marcelis
    Playwright in Pictures: Fully Parallel Modeplaywright

    Playwright in Pictures: Fully Parallel Mode

    Playwright’s fullyParallel mode is often treated as a simple performance switch. In practice, it...

    V
    Vitaliy Potapov
    Designing a CLI for Both Humans and Agentscli

    Designing a CLI for Both Humans and Agents

    Learn how Alpic designed its CLI for both human developers and AI agents — covering tradeoffs like polling, context windows, interactivity, and statelessness.

    J
    Julien Vallini

    Stay up to date

    Get the latest DeepSeek prompts, rules, and resources delivered to your inbox weekly.

    Neura Market LogoNeura Market

    Discover the best AI prompts, plugins, and resources for DeepSeek and more.

    Content Types

    • Rules
    • Prompts
    • MCPs
    • Agents
    • Guides

    Platforms

    • ChatGPT Directory
    • Claude Directory
    • Gemini Directory
    • Cursor Directory
    • Grok Directory
    • Perplexity Directory
    • DeepSeek Directory
    • CoPilot Directory
    • Stable Diffusion Directory
    • Midjourney Directory
    • All Directories

    Resources

    • Blog
    • Documentation
    • Help Center
    • Marketplace

    Legal

    • Privacy Policy
    • Terms of Service

    © 2026 Neura Market. All rights reserved.

    |

    Not affiliated with any AI platform vendors.