Introduction

In the world of Exploratory Domain Discovery, one of the most critical aspects of understanding and designing complex systems is identifying the main point. But what exactly does the main point refer to? In EDD, the main point is the core idea that drives a domain, whether from a software perspective or a business perspective. Recognizing this central concept is vital for ensuring that the solution addresses the right problem and delivers the intended value.

In this article, I’ll explore two levels of the main point: the software-level main point and the real-business main point. I’ll dive into their significance, their crucial role in software design, and provide heuristics for discovering them, with an example from the accounting domain.

The What Part

First I should say that when i talk about a main point, that means the main point of a story. The main point of a story is the central idea or message that drives its entire narrative. Whether in a book, movie, or historical event, the context of the story is carefully constructed to highlight and support this main point. If you change the main point, the context must also shift to maintain coherence and clarity.

Example: The Little Match Girl

In The Little Match Girl by Hans Christian Andersen, the context includes the cold, snowy streets, the little girl trying to sell matches, and her poor, sad situation. These details create the setting for the story.

However, the main point of the story is simpler: It shows how the little girl, despite her suffering, finds moments of hope and warmth in her imagination as she lights the matches. The story is about the contrast between her hard life and the peaceful visions she sees when she lights each match.

If you changed the main point—for example, focusing on how the people around her react—the whole context, like her dreams and the match lighting, would need to change too. The message of the story would be different. By finding the main point, we can understand the deeper meaning behind her tragic situation.

Every complex software has a domain, which it is supposed to solve problems within using software. Therefore, every software we are developing has a problem area called a domain. Every domain has its own story. Wow, a story! If we agree that almost all stories consist of approximately 99.99% context provided to convey clear key ideas, then this is obviously true for the story of the domain of the software we are developing right now.

⚠️😶‍🌫️👀Believe me, every story consists of more than 99.99% context provided to convey a key or main point.

Main Point in EDD

In Exploratory Domain Discovery, the domain we are exploring is like a story. EDD focuses on uncovering this main point to guide us in solving the problem, ensuring we are addressing the true core of the issue. Through the EDD process, we aim to identify and understand this central message, which helps keep the development efforts aligned with the desired outcome.

The Importance: The Why Part

You:

Alright, Masoud, I think I’m starting to get your point about the main point and context in a story. But how does this actually relate to software development? Why should I, as a developer, architect, or product owner, care about finding the main point in my work?

Masoud:

Hmm, to put it simply: like the north star, the main point acts as the cornerstone of your model and design. —it’s the guiding principle that keeps everything aligned. Everything else revolves around it.

What do you think—should we start with the north star and build everything around it, or do we try to fit it all together afterward?

You:

You’re making me crazy here, Masoud! I get the metaphor, but can you give me a real example? Show me how this works in practice!

Masoud, do you remember: Talk is cheap, give me an example?

Masoud:

Alright, alright, let’s dig into a real-world example. Let’s think about Accounting Software(sorry about that!). Imagine you’re designing this system—what would you say is the most important part? Would it be the financial year, the chart of accounts, subledger accounts, financial transactions, or the journals and ledgers?

Hmm… I guess all of those elements are important, right? How can I choose which one is the main point?

Here’s the key: the main point—the core focus of your software—determines how you structure everything else. Let’s say the ‘north star’ of your model is a subledger account. In that case, everything else in the system revolves around subledger accounts. So, your financial transactions, journal entries, and reports would be designed to support the creation, management, and tracking of those accounts.

On the other hand, let’s say the main point is a financial transaction. In that case, the transactions are the heart of the system, and everything else—like subledger accounts, journals, and reports—serves the purpose of capturing and organizing the transactions. Does that make sense?

Got it! So if the subledger account is the main point, the whole system revolves around managing and categorizing those accounts. But if the transaction is the main point, everything else exists to process, record, and report on those transactions.

Exactly! It’s all about where you anchor the focus. Think about it like setting the foundation for a building—you need to decide where to put the cornerstone, because it will shape the entire structure.

Okay, but how do we decide which one should be the main point? Is there a rule, or does it depend on the business?

Good question. It really depends on the business needs and goals. For example, let’s say your accounting software is being used by a small business. If they need detailed tracking and reporting for each individual subledger account, the subledger account might be the best ‘north star.’ But if the primary concern is ensuring the smooth processing of transactions—maybe for real-time financial updates—the financial transaction becomes the main point.

For a concrete example, let’s say a company needs to audit its financial records. If the system focuses on subledger accounts, it might be easier to see the details of each account, making it easier to track balances and discrepancies. But if the focus is on transactions, the system might be designed to capture every financial movement in real-time, which could help with things like cash flow analysis or detecting errors quickly.

So the key is to align the main point with the business priorities. If the business cares more about managing accounts and auditing balances, focus on the subledger account. But if they’re more concerned with processing transactions quickly and efficiently, focus on the transactions themselves.

Exactly! It’s all about understanding what’s most important to the business and structuring the software accordingly. The main point gives you direction, and from there, everything else falls into place. And remember, once you’ve identified the main point, everything else should serve and support that point—just like in a good story!

Ah, I see it now. Thanks, Masoud! You’ve cleared up a lot of confusion. Now I can see how picking the main point upfront makes the whole design process easier and more aligned with what the business actually needs.

Glad to hear it! Remember, when you’re deep into the weeds of development, always come back to the main point. It’ll help you avoid getting lost in all the extra context and ensure your software does exactly what it needs to do.

Example

Let’s break this down with a more concrete example.

Example 1: Subledger Account as the Main Point

In this case, the subledger account is the core focus of the system. All other elements, like financial transactions, journal entries, and reports, will revolve around the subledger account. Here’s how the structure might look:

public class SubledgerAccount
{
    public string AccountId { get; set; }
    public string AccountName { get; set; }
    public decimal Balance { get; set; }

    public void UpdateBalance(decimal amount, bool isDebit)
    {
        if (isDebit)
        {
            Balance -= amount;
        }
        else
        {
            Balance += amount;
        }
    }
}

public class FinancialTransaction
{
    public string TransactionId { get; set; }
    public decimal Amount { get; set; }
    public SubledgerAccount DebitAccount { get; set; }
    public SubledgerAccount CreditAccount { get; set; }

    public void ApplyTransaction()
    {
        DebitAccount.Post(Amount, true);
        CreditAccount.Post(Amount, false);
    }
}

In this design, the SubledgerAccount is the center of the system. The Transaction is created in the context of this account, and all transactions modify the balance of this subledger account. Reports are also generated based on the data contained in the subledger account.

Example 2: Financial Transaction as the Main Point

Now, let’s consider the financial transaction as the main point of focus. The Transaction becomes the core element, and everything else (such as subledger accounts, journals, and reports) supports it. Here’s how the system would look:

public class SubledgerAccount
{
    public string AccountId { get; set; }
    public string AccountName { get; set; }

    public decimal GetBalance(List<FinancialTransaction> transactions)
    {
        decimal balance = 0;

        foreach (var transaction in transactions)
        {
            if (transaction.DebitAccount.AccountId == AccountId)
            {
                balance -= transaction.Amount;
            }
            if (transaction.CreditAccount.AccountId == AccountId)
            {
                balance += transaction.Amount;
            }
        }

        return balance;
    }
}

public class FinancialTransaction
{
    public string TransactionId { get; set; }
    public decimal Amount { get; set; }
    public SubledgerAccount DebitAccount { get; set; }
    public SubledgerAccount CreditAccount { get; set; }

    // No immediate effect on SubledgerAccount balances
    public void RecordTransaction() { }
}

In this version, the Transaction is the main point. Every transaction is an independent entity and must be applied to the relevant SubledgerAccount. In this case, the subledger account acts as a supporting element, simply storing and updating its balance when a transaction occurs. The subledger account has a method to update its balance, but the transaction is the primary object being processed.

The Software-Level Main Point

The software-level main point refers to the central idea or core concept that drives the design and structure of the software system. This main point serves as the guiding force that influences how various elements of the system are constructed, organized, and related to each other. It helps ensure that the software remains focused on solving the right problem, serving the right needs, and achieving its intended goals.

In the case of an accounting software system, for example, the software-level main point could either be the subledger account or the financial transaction, depending on the specific focus of the system. Let’s explore both scenarios:

• Subledger Account as the North Star:
  If we consider the subledger account as the core focus, the software’s primary design will revolve around managing and tracking the balances of various accounts.
• Financial Transaction as the North Star:
  Alternatively, if the financial transaction is considered the north star, the software is designed to record and manage individual transactions, which are linked to specific subledger accounts.

The software-level main point is foundational because it establishes how the system will be structured and what role each component plays in the solution. Choosing the right main point determines how data is modeled, how business logic is implemented, and how interactions between components occur.

The Business-Wise Main Point

The real-business main point reflects the primary goal or key problem that the software is designed to solve in the real world. It is concerned with the actual business domain and the needs of the business. The main point at this level helps ensure that the software aligns with the goals of the organization and the challenges faced by users.

In the context of accounting software, the real-business main point may not always align with the technical aspects of the system (such as transactions or accounts). Instead, the real-business main point focuses on accurately tracking financial data, ensuring regulatory compliance, or generating meaningful financial reports that help business decision-makers.

Understanding the real-business main point is critical because it ensures that the software’s design aligns with the company’s strategic objectives and helps solve real-world business problems. Without it, software solutions might become overly complex or misaligned with what the business truly needs.

Connecting the Software-Level and Business-Level Main Points

The software-level main point and the real-business main point must be connected for a successful system. While the software-level main point defines how the system will be structured, the real-business main point ensures that the system solves real-world problems and provides value to users and stakeholders.

Here’s how to connect the two:

• Alignment with Business Objectives:
  Once you’ve identified the real-business main point (e.g., ensuring accurate financial reporting), ensure that your software’s design (e.g., the focus on financial transactions or subledger accounts for example) supports this goal. In the case of accounting software, if the business goal is to provide transparency and compliance, the software design may revolve around financial transactions, ensuring traceability from the transaction to the final report.
• Mapping Entities to Business Goals:
  Connect software entities (such as subledger accounts or financial transactions) to business goals. For example, if the business goal is to automate reconciliation, then subledger accounts may be the main point in the software to facilitate that automation. Similarly, if the business needs detailed transaction records, the financial transaction could become the core entity, with everything else supporting it.
• Evolving Together:
  Both the software and business goals evolve over time. Keep in mind that your software model should remain flexible enough to adapt to changing business needs. As new business requirements emerge (e.g., tax regulations, market changes), the system’s design (e.g., how it handles financial transactions) may need to adjust while still supporting the core business objective.
• Feedback Loops:
  It’s essential to establish feedback loops between the software development team and the business stakeholders. This allows you to continuously ensure that the system remains aligned with the real-business main point. As you refine the software design, you may discover new insights into the business needs, allowing you to adjust the focus of your software accordingly.

In The Following

I’ll also be diving into two other areas: how heuristics can help us find the main point, and the importance of domain circularity patterns in that process. More to come!

So be tuned!