Building a PHP CLI tool using DDD and Event Sourcing: the domain

Last updated: 2023-07-10 :: Published: 2022-08-17 :: [ history ]

Been here before?

Get notified of future posts by email:

You can also subscribe to the RSS or Atom feed, or follow me on Twitter.

Time to sit with the experts

The first D of DDD stands for Domain. This is where we start.

The word domain can mean a number of things, but in the context of DDD and of this series, we'll use two definitions from Wiktionary:

1) A field or sphere of activity, influence or expertise
2) A group of related items, topics, or subjects

While these definitions are still fairly loose, they encompass the main ideas behind the type of domain we're trying to identify – a group of related concepts and ideas about a field, articulated by experts in that field.

In this series

• Why?
• The domain ⬅️ you are here
• The model
• Software design
• Setting up Laravel Zero
• Getting started with EventSauce
• Distribution

In this post

What is the domain for?

The process roughly goes like this – domain experts describe what they do and go through the rules applying to various scenarios, guided by our questions and what we aim to achieve with the software. The goal is to gather as much information as possible to later try and identify the key concepts of the domain.

Expressing the domain is also a way to get familiar with its lexical field, to remove ambiguity from terms that may eventually find their way to the model. In doing so, we lay the foundation of the ubiquitous language, the language to be used consistently across all communications, both by the team and the experts.

The result won't be 100% complete nor correct, but it's a starting point. The next phases – modelling and designing – will help further determine what bits of information are important and what can be ignored. Sometimes, these steps will uncover elements missing from the domain, which we will need to amend with the help of the experts.

In turn, these new elements will reshape the model and flow into the code, each phase feeding into the others, creating a feedback loop where each iteration gets us closer to the truth.

Who are the experts?

A key element of DDD is to identify the relevant experts. When it comes to the tool serving as a backdrop for this series, one group of professionals naturally comes to mind – accountants. They know the rules that apply to crypto transactions and can confirm whether the implemented logic yields the correct results.

As rule issuers, another essential group of experts is HMRC – the UK Government's department responsible for the collection of taxes. While I am not in direct contact with an HMRC agent, there is a fairly comprehensive Cryptoassets Manual available online for anyone to consult.

But in this case, there's also a third, less obvious expert that can inform the domain – myself. I want to write a program that reflects my crypto activity, of which I'm an "expert" of some sort. I know the types of transactions I need to ask about, allowing me to guide the conversation so that, together with the other experts, we express a subset of the domain that is relevant to the future software.

To facilitate this, I laid out the use cases I was particularly interested in, preemptively narrowing down the domain. I sent those use cases to my accountant, who explained the applicable rules and, later on, confirmed whether the example calculations I had submitted were correct.

The domain

So what are those use cases? I've listed them below, with some context and illustrative examples. Together with some more general aspects of the UK tax regime, they constitute the domain.

Note that it isn't set in stone. It is very likely that as the field of crypto and web3 expands, so too will my crypto activity, forcing me to revisit the domain, complete the model and update its implementation.

HMRC rules are also likely to evolve, prompting similar changes.

Disclaimer The below is correct to the best of my knowledge and I implemented the corresponding rules accordingly. But I am not an accountant and therefore cannot guarantee the complete accuracy of the following examples at any given time. Please speak to a professional before using this material for tax purposes.

Also The following rules and examples are sometimes complicated and full of jargon (that's the point). I have to lay them out as part of the exercise of expressing the domain as precisely as possible, but of course if you're not really interested in knowing how it all works, you're welcome to skim through or even jump ahead to the closing thoughts.

The basics

We need to cover a few basics before digging into specific use cases.

First, in the UK the fiscal year or tax year runs from April 6 to April 5.

Second, most types of taxes have an allowance under which proceeds are tax-free. For instance, the 2022-23 tax year has the following allowances:

• the Income Tax doesn't apply to the first £12,570 of revenue;
• the Capital Gains Tax doesn't apply to the first £12,300 of capital gains.

In the examples below, it is implied that these tax regimes only apply to amounts greater than the allowances.

Finally, a high-level way to describe what we're trying to achieve here is that we intend to analyse a bunch of transactions in chronological order so we can extract and output information that can be used for tax purposes, effectively generating a summary for each tax year.

Trading?

Something else that we need to get out of the way right now is whether one's crypto activity is considered to be trading:

Only in exceptional circumstances would HMRC expect individuals to buy and sell exchange tokens with such frequency, level of organisation and sophistication that the activity amounts to a financial trade in itself. If the taxpayer’s activity is considered to be trading then Income Tax will take priority over Capital Gains Tax and will apply to profits (or losses).

– The Cryptoassets Manual

Most people's crypto activity falls under the Capital Gains Tax regime, but in certain circumstances – e.g. a high number of transactions, crypto being the main source of income, etc. – this activity could fall under the Income Tax regime (the regime applying to regular job salaries).

In my case though, crypto is definitely a hobby, so Capital Gains Tax applies.

Fiat conversions

Another side topic to address early on is the conversion from one fiat currency to another.

A fiat currency is a government-issued currency, such as the euro or the British pound. Not all my transactions are conducted in pounds, and as we'll see further down it is sometimes necessary to get price information from third-party websites denominating prices in a different currency.

HMRC issue monthly exchange rates that they publish on their website for each year. These rates should be used when needing to convert amounts to pounds.

Buying and selling

Under Capital Gains Tax, cryptocurrencies are referred to as assets or tokens. Each asset has a name but also a symbol, or ticker, which is the same thing as a company's stock abbreviation (e.g. the symbol for the bitcoin token is BTC).

When one buys an asset at a certain price and then sells this asset, if the obtained amount (the proceeds) is greater than the initial purchase price (the cost basis), then a gain has been realised.

The gain is the difference between the cost basis and the proceeds, and this amount is subject to Capital Gains Tax.

If, on the contrary, the proceeds are less than the cost basis, a loss has been realised and the difference can be deducted from gains acquired elsewhere.

Selling an asset is also referred to as a disposal – a broader category of taxable events comprising:

• selling the asset for fiat currency;
• exchanging the asset for another asset;
• using the asset to purchase goods and services; and
• giving away the asset (unless to a spouse or civil partner).

Let's unpack those.

Selling an asset for fiat currency

Buying an asset with fiat currency and selling it for the same currency is the most straightforward scenario from an accounting perspective. Investors need to keep track of the cost basis of an asset acquisition and calculate whether a gain or loss is realised upon selling the asset.

Example Alice buys 5 ethers for £5,000. She then sells 3 of these ethers for £4,000. She initially bought these ethers at a unit price of £5,000 / 5 = £1,000, meaning the cost basis of the disposal is £1,000 * 3 = £3,000. Alice made a £4,000 - £3,000 = £1,000 gain, which is subject to Capital Gains Tax.

Some people buy and accumulate an asset over time, sometimes through regular automated purchases (a strategy called dollar-cost averaging). In that case, the way to calculate capital gains or losses differs based on when the asset is disposed of, following the rules of share pooling.

The main idea of share pooling is that when an asset is acquired, it goes into a pool. That pool then grows or shrinks as more of the asset is acquired or disposed of. We calculate the cost basis of a disposal using the average cost basis of each purchase that flowed into the pool up to the date of the disposal.

This pool is also referred to as a Section 104 pool or Section 104 holding.

Example Bob buys 2 ethers for £2,000. A few days later, he buys 2 more ethers for £3,000. He now has 4 ethers in the pool, for an average cost basis of (£2,000 + £3,000) / 4 = £1,250 per unit. A month later he decides to sell 3 ethers for £6,000. He made a £6,000 - (3 * £1,250) = £2,250 gain, which is subject to Capital Gains Tax.

There is a couple of scenarios in which the Section 104 rule doesn't apply. The first one is called the same-day rule and covers the case where several operations involving the same asset happen on the same day.

Calendar days Note that we are referring to calendar days here, not 24-hour slots. For instance, if an asset was bought on Monday at 11 pm and then sold on Tuesday at 1 am, these are different days and the same-day rule does not apply.

One such scenario is when an asset is disposed of on the same day that it was acquired. When that happens, we use the cost basis of the purchases of that asset on that day, ignoring past acquisitions that may have flowed into a Section 104 pool.

Example On Monday, Charlie buys 1 ether for £1,000, which goes into a new Section 104 pool. On Tuesday, he buys another ether for £1,100. Later that day, he sells 1 ether for £1,200. Since he sold 1 ether on the same day he bought one, the latter doesn't flow into the Section 104 pool and forms the cost basis of the sale – £1,100. Charlie made a £1,200 - £1,100 = £100 gain, which is subject to Capital Gains Tax.

What happens if the amount sold is greater than the other amounts purchased that day? In that case, we fall back to the Section 104 rule for the remainder of the amount.

Example On Monday, Alice buys 2 ethers for £2,000. On Tuesday, she buys another ether for £1,100. Later that day, she sells 2 ethers for £2,400. Since she bought 1 ether on the same day, its cost basis forms the cost basis of the first ether sold – £1,100. The cost basis of the second ether sold is the average cost basis of the Section 104 pool, so £2,000 / 2 = £1,000 per unit. Alice made a £2,400 - (£1,100 + £1,000) = £300 gain, which is subject to Capital Gains Tax.

But there's more. The same-day rule also applies if you buy back the asset on the same day, after you've sold it. The cost basis of the buy-back is then used to calculate the cost basis of the amount sold.

Example On Monday, Bob buys 3 ethers for £3,000. On Tuesday, he sells 2 ethers for £2,500. Later that day, he buys 1 ether for £1,100. Since he bought back 1 ether on the same day he sold 2, the cost basis of the first ether sold is the cost basis of the ether he bought back. The cost basis of the second ether sold is the average cost basis of the Section 104 pool, so £3,000 / 3 = £1,000 per unit. Bob made a £2,500 - (£1,100 + £1,000) = £400 gain, which is subject to Capital Gains Tax.

Finally, if you happen to purchase the same asset several times on the same day, at different prices, you need to use the average cost basis of the acquisitions to calculate the cost basis of all the disposals on that day, essentially treating all acquisitions and all disposals as a single acquisition and a single disposal, respectively:

All shares of the same class in the same company acquired by the same person on the same day and in the same capacity are treated as though they were acquired by a single transaction, TCGA92/S105 (1)(a).

All shares of the same class in the same company disposed of by the same person on the same day and in the same capacity are also treated as though they were disposed of by a single transaction, TCGA92/S105 (1)(a).

– The Capital Gains Manual

That's it for the same-day rule. So what's the second scenario in which the Section 104 rule doesn't apply? It's the 30-day rule (also referred to as bed and breakfasting), which concerns assets being bought back within 30 days of being sold.

The rule works in the same way as the last same-day rule example above, by taking into account the cost basis of the buy-back for the calculation of the cost basis of the amount initially sold.

Example On Monday, Charlie buys 3 ethers for £3,000. On Tuesday, he sells 2 ethers for £2,500. Then, that Sunday, he buys back 1 ether for £900. Since he bought back 1 ether within 30 days of selling 2, the cost basis of the first ether sold is the cost basis of the ether he bought back. The cost basis of the second ether sold is the average cost basis of the Section 104 pool, so £3,000 / 3 = £1,000 per unit. Charlie made a £2,500 - (£900 + £1,000) = £600 gain, which is subject to Capital Gains Tax.

Note that because of this rule, you may want to wait for at least 30 days after the end of the tax year to compute your capital gains and losses, in case transactions falling under the 30-day rule occur in that window.

Why is it so complicated? These rules exist to prevent a practice called wash sale. The idea is that an investor sells an asset at a loss to record that loss and thus reduce his tax liability, and then repurchases the asset shortly thereafter to maintain his exposure to it. The same-day and 30-day rules help mitigate this practice.

Exchanging an asset for another asset

Buying and selling from and to fiat is a common use case, but many investors also exchange (or swap) assets for other assets. These conversions also qualify as disposals (of the original asset) and are taxable events, even if no fiat currency is involved.

In that case, it's the investor's job to determine the cost basis of the operation, by finding out the market value of the sold asset in fiat terms at the time of the transaction. That market value should be taken from the exchange on which the swap was conducted if available, and from price-tracking websites such as CoinMarketCap or CoinGecko if not.

Example Bob buys 2 ethers for £2,000. A few days later, he swaps 1 ether for 0.1 bitcoins. He looks up the market value of the ETH token at the time of the swap and notes that it was £1,500 per ether. As a result, Bob made a £1,500 - (£2,000 / 2) = £500 gain with this transaction, which is subject to Capital Gains Tax. Bob eventually sells the 0.1 bitcoins for £2,100. The cost basis of the acquired 0.1 bitcoins was £1,500, so Bob made another gain of £2,100 - £1,500 = £600, which is also subject to Capital Gains Tax.

Note that the rules of share pooling also apply here – the only difference is that the cost basis in fiat terms must be established beforehand.

What if the asset is not listed? If the market value of one of the assets involved in the transaction isn't tracked anywhere, the market value of the other asset can be used instead. If none of the assets' market values is tracked, the investor must determine the fair market value of the disposed asset. It is unclear how to do that, however.

Using an asset to purchase goods and services

On a few occasions, I used cryptocurrency to purchase some goods. This kind of operation is also a disposal and is equivalent to selling the corresponding asset for the price of the good in fiat terms.

When the good isn't priced in fiat at all, the investor is supposed to figure out its fair market value. Typically, that’s the market value of the asset sold for the good at the time of the transaction, as reported by a price-tracking platform like mentioned earlier.

Example Charlie buys 0.5 bitcoins for £10,000, at a unit price of £20,000 per bitcoin. He wants to attend an event whose tickets are exclusively priced in bitcoin, at 0.1 bitcoins each. Charlie looks up the market value of the BTC token at the time of the purchase and notes that it was £21,000 per bitcoin. As a result, Charlie made a (£21,000 * 0.1) - (£20,000 * 0.1) = £100 gain with this transaction, which is subject to Capital Gains Tax.

Keep in mind that here too, share-pooling rules apply.

Fees in fiat

Most exchanges charge a fee for the following operations:

• purchasing an asset with fiat currency;
• selling an asset for fiat currency; and
• swapping an asset for another.

This type of fee is part of the allowable expenses or allowable costs, and it can be deducted.

When buying an asset with fiat currency, the fee must be included in the cost basis:

Example Alice buys 2 ethers for £2,000 on an exchange. The exchange charges a £20 fee to execute the transaction. The cost basis of the 2 ethers is then £2,000 + £20 = £2,020, so a unit price of £1,010.

When selling an asset for fiat currency, the fee must be excluded from the proceeds:

Example A couple of months later, Alice sells one of her ethers for £2,500 on the same exchange. The exchange charges a £25 fee to execute the transaction. Alice made a (£2,500 - £25) - (£1,010 * 1) = £1,465 gain, which is subject to Capital Gains Tax.

Finally, when swapping an asset for another, the fee can either be excluded from the proceeds of the disposed asset or included in the cost basis of the acquired asset:

Exchange (swap) token A for token B: the fee paid is in relation to the whole of the transaction, that is for a disposal of one asset and the acquisition of another asset. This means that the fee is attributable to both assets. HMRC’s view is that this fee would be allowable as a deduction in computing the disposal in respect of token A under section 38(1)(c), and that it would be allowable as a deduction in computing the eventual disposal of token B under section 38(1)(a). TCGA92/S52(1) makes it clear that a sum may be allowed as a deduction only once in computing a disposal.

– The Cryptoassets Manual

But there is also a third way:

Where an allowable cost relates to more than one asset, the cost should be apportioned between those assets on a just and reasonable basis (TCGA92/S52(4)). You can accept that apportioning this type of fee equally between the assets disposed of and the assets acquired (that is a 50/50 split) is just and reasonable in these circumstances.

– The Cryptoassets Manual

This means that the fee can also be split in half – 50% is excluded from the proceeds of the disposed asset and the other 50% is included in the cost basis of the acquired asset.

Example Alice swaps her remaining ether for 0.1 bitcoins on the same exchange. The exchange charges a £10 fee to execute the transaction. Alice looks up the market value of the ETH token at the time of the transaction and notes that it was £3,000 per ether. As 50% of the fee must be excluded from the market value of the disposed ether, Alice made a £3,000 - (£10 / 2) - £1,010 = £1,985 gain with this transaction, which is subject to Capital Gains Tax. As 50% of the fee must be included in the cost basis of the acquired bitcoins, the corresponding amount is £3,000 + (£10 / 2) = £3,005.

Things are slowly getting complicated, but the real fun starts when transaction fees are settled in cryptocurrency.

Fees in cryptocurrency

The HMRC Cryptoassets Manual has a page dedicated to fees satisfied in tokens. These fees can be issued by exchanges (e.g. when swapping an asset for another) or be associated with the operating costs of the underlying network (e.g. the blockchain). The latter include transferring an asset from one wallet to another, for instance.

Fees settled in cryptocurrency are treated differently because they are both an allowable cost and a disposal:

Most cryptoasset transactions require the person disposing of the tokens to pay a fee. This fee will often be satisfied in tokens. If the transaction fee is satisfied in tokens then you need to consider that fee as one of the costs for the disposal of the tokens, but you also need to consider the fee as a disposal in its own right.

– The Cryptoassets Manual

This means that in a swapping transaction whose fee is settled in cryptocurrency, and when following the fee-split rule, not only 50% of the market value of the fee must be excluded from the proceeds of the disposed asset and the other 50% included in the cost basis of the acquired asset, but the entire market value of the fee must also be counted as a disposal, following the share-pooling rules. Read that again.

How about transferring an asset from one wallet to another? As long as you are the owner of both wallets, there is no capital gain to report on the transferred amount:

There is no disposal if the individual retains beneficial ownership of the tokens throughout the transaction, for example moving tokens between public addresses that the individual beneficially controls (commonly described as moving tokens between wallets).

– The Cryptoassets Manual

The transaction fee, however, constitutes an asset disposal subject to Capital Gains Tax. It is also an allowable cost, although it is not attributable to an asset – this is a non-attributable allowable cost. The investor should keep track of these and deduct them from the capital gains when completing his tax return.

Example Charlie buys 1 ether for £1,000 on an exchange. A few months later he acquires a hardware wallet and decides to move his ether to it. The transaction incurs a fee of 0.01 ethers. Charlie looks up the market value of the ETH token at the time of the transaction and notes that it was £2,000 per ether. Charlie made a (£2,000 * 0.01) - (£1,000 * 0.01) = £10 gain, which is subject to Capital Gains Tax. The transaction fee is also an allowable cost of £2,000 * 0.01 = £20, deductible from capital gains.

Decentralised Finance

Decentralised finance or DeFi aims at offering a range of financial services built on top of blockchain technology, without centralised intermediaries. DeFi protocols are extremely varied and the returns they generate can either be considered as income or capital gains based on various criteria:

How the return is taxed upon receipt by the lender/liquidity provider will depend on whether the return has the nature of capital or revenue. The nature of the return received by the lender/liquidity provider will depend on how the transaction is structured.

– The Cryptoassets Manual

I have only dabbed a little in DeFi and thankfully the protocol I’ve been using seems to fall under the "return has the nature of capital" category, which will make the corresponding tax calculations similar to that of regular crypto-to-crypto transactions.

Non-Fungible Tokens

Non-Fungible Tokens or NFTs are also subject to Capital Gains Tax. But the key difference with fungible tokens (e.g. bitcoins or ethers) is that, because of their uniqueness, share-pooling rules don't apply to them:

Non-Fungible Tokens (NFTs) are separately identifiable and so are not pooled.

– The Cryptoassets Manual

Example Bob buys an NFT on a platform for £500. Later that day, he sells it for £600, making a £100 gain which is subject to Capital Gains Tax. A week later, he buys the same NFT again for £400. Because share-pooling rules don't apply, the cost basis of the sold NFT is still £500. Bob made a £600 - £500 = £100 gain, which is subject to Capital Gains Tax.

Where it gets tricky in my case is that I minted (created) some NFTs in exotic ways, for instance by burning several NFTs to create a new one. In that case, the cost basis of the new NFT is the sum of the cost bases of the burnt NFTs.

Example Charlie buys an NFT depicting a lion for £500. He then successively buys an NFT of a goat for £300 and an NFT of a snake for £400. He burns the three NFTs to mint a new NFT, depicting the Chimera. A few days later, he sells the Chimera NFT for £2,000. Charlie made a £2,000 - (£500 + £300 + £400) = £800 gain, which is subject to Capital Gains Tax.

Airdrops

Airdrops are a way for developers to distribute an asset and kickstart a community. The corresponding tokens can either be sent to wallet addresses directly or claimed by investors:

An airdrop is when an individual receives an allocation of tokens. For example, tokens that are given as part of a marketing or advertising campaign.

– The Cryptoassets Manual

Airdropped tokens also follow the rules of share pooling – they go to a new Section 104 pool if the investor didn't hold any yet or flow into the existing pool if she did. Their cost basis is the market value of the asset at the time it was airdropped.

But airdropped tokens are a bit special – they can also be considered as income when recipients qualifying for the airdrop are so because of some past activity:

Income Tax will not always apply to airdropped tokens received in a personal capacity. Income Tax may not apply if they’re received:

• without doing anything in return (for example, not related to any service or other conditions)
• not as part of a trade or business involving cryptoasset exchange tokens or mining

Airdrops that are provided in return for, or in expectation of, a service are subject to Income Tax either as:

• miscellaneous income
• receipts of an existing trade

– The Cryptoassets Manual

Example The reason Alice received the 100 MEOW tokens in the first place is that she opened a Cat wallet a few months prior to the airdrop. Since the price of the MEOW token at the time of the transaction was £1 per MEOW, Alice received 100 * £1 = £100 as income, which is subject to Income Tax.

This is something to keep in mind when you qualify for an airdrop – if the airdrop is not directly sent to your wallet and you have to claim it instead, it could be a good idea to wait for a price drop before claiming the token.

Hard forks

A fork occurs when the protocol underlying the blockchain receives an upgrade.

There are two types of forks – the soft forks and the hard forks. Soft forks happen when the changes are backward-compatible (like a patch, or a minor version release like in Semantic Versioning), while hard forks occur when the new version of the protocol isn't compatible with the old one (like a major version release, with breaking changes).

In the latter case, when there is still significant support for the old version of the protocol, the old blockchain lives on and both blockchains go their separate ways, independently from each other.

This often leads to the creation of two separate assets:

There are two types of forks, a soft fork and a hard fork. A soft fork updates the protocol and is intended to be adopted by all. No new tokens, or distributed ledger, are expected to be created. A hard fork is different and can result in new tokens coming into existence. Before the fork occurs there is a single distributed ledger. Usually, at the point of the hard fork a second branch (and therefore a new cryptoasset) is created.

– The Cryptoassets Manual

Holders of the original asset usually receive the newly created asset at a 1:1 ratio, using a snapshot of the original blockchain as reference.

For tax-treatment purposes, the new asset goes to its own Section 104 pool and its cost basis is derived from the original asset (which is different from airdrops, where we assign the market value of the asset at the time it was airdropped). This means that the average cost basis of the original asset can be split between the two assets.

It is also allowed to maintain the average cost basis of the original asset as it is, and to assign a zero cost basis to the new asset instead, which is simpler:

Example Bob was holding 5 bitcoins (BTC) when the Bitcoin Cash fork occurred in 2017. As a result, he received 5 BCH. Bob later sold his 5 BCH for £1,000. As the cost basis for the acquisition of the 5 BCH was 0, Bob made a £1,000 gain, which is subject to Capital Gains Tax.

Gifts

Finally, when receiving an asset as a gift from someone who is not your spouse or civil partner, you need to work out the price of the asset in fiat terms at the time of the transaction and use it as the cost basis of the asset when you dispose of it.

Example Charlie receives 0.1 bitcoins from his sister. He later sells them for £2,200. Charlie looks up the market value of the BTC token at the time of the gift and notes that it was £20,000 per bitcoin. As a result, Charlie made a £2,200 - (£20,000 * 0.1) = £200 gain, which is subject to Capital Gains Tax.

The gift in and of itself is not a taxable event for the person receiving it, but is subject to Capital Gains Tax for the person making it, following the same rules as any other disposal.

Even though I am not concerned by this scenario at the time of writing, it is also worth looking into gifts coming from a spouse or civil partner, as I couldn't find this information in the HMRC Cryptoassets Manual and it was brought up during a conversation with a specialised accountant instead.

When an asset is gifted to a spouse or civil partner, the transaction is not considered a taxable event for either of the parties, and the cost basis of the disposal is the cost basis of the initial acquisition by the person making the gift.

Example Alice gifts 2 ethers previously acquired for £2,000 to her spouse. Alice looks up the price of the ETH token at the time of the gift and notes that it was £1,500 per ether. But since she gifted the ethers to her spouse, the transaction doesn’t constitute a taxable event. A few months later, Alice's spouse sells the 2 ethers for £4,000. But since he got these ethers from his spouse in the first place, their cost basis is not the market value at the time of the gift, but at the time Alice first acquired the ethers. Alice's spouse made a £4,000 - £2,000 = £2,000 gain, which is subject to Capital Gains Tax.

Closing thoughts

Coming up with the domain can be a bit messy. Even though I was able to narrow it down from the get-go by focussing on my specific use cases, there is still a lot of information – a good chunk of which will turn out to be noise.

Some of the rules and examples laid out in this article are rather complicated and some of it may have gone over your head. That's OK. Then again, this series is not so much about crypto taxes as it is about building an application following a DDD approach. The main goal of this post was to give you an idea of what a domain is and how to express it.

While I've tried to emphasise the terms which I think are good candidates for the ubiquitous language, at this stage I don't know for sure which bits will make it to the model. That will be the focus of the next part of the series.

Subscribe to email alerts below so you don't miss it, or follow me on Twitter where I will share it as soon as it is available.

Enjoying the content?

Get notified of future posts by email:

You can also subscribe to the RSS or Atom feed, or follow me on Twitter.

Last updated by osteel on 2023-07-10 :: [ ddd ]

Comments