Mustafa's zettelkasten 📔
Search
Search
Search
Dark mode
Light mode
Explorer
output
Complexity In Software Design
How Building a Personal Knowledge Base Helping me as a Software Engineer
Why Code Comments Is More Important Than You Think
Zettelkasten with obsidian
zettelkasten
homelab
HomeLab - Index
homelab - install k3s on ubuntu
homelab - running pihole on ubuntu server
homelab - running private docker registry
homelab - running private docker registry 1
PKM
avoid cramming
avoid multitasking
become an expert by practicing
Building a Seconded Brain
building notes bottom-up
comparing notes
fleeting notes
Folgezettel
get laser-focused
how to add new permanent notes
how to avoid confirmation bias when taking notes
How to Take Smart Notes
HTNS - let the work carry you forward
HTNS - nobody ever starts from scratch
HTNS - note categories
HTNS - note taking mistakes
HTSN - Everything You Need To Do
HTSN - Everything You Need To Know
HTSN - simplicity is essential
HTSN - Steps To Successful Writing
HTSN - Writing a Paper step-by-step
HTSN - writing is the only thing that matters
improve thinking by making permanent notes
improve understanding with literature notes
index notes
knowledge building blocks
knowledge workers
literature notes
Luhmann's ZettelKasten
make a career one note at a time
Niklas Luhmann
On Writing Well
PARA
permanent notes
personal knowledge between past and present
PKM - Index
project notes
Rapid Logging
reduce the number of decisions
reference notes
taking notes and quotes from content to your PKM
understand what you read
Writing To Learn
zettelkasten
technical
3 ways to corrupt your data when using transaction script
100% is the wrong reliability target
abstraction
ACID
Acing System Design Interviews
active record pattern
adapter design pattern
amdahl's law
application performance management
availability and reliability
behavioural design patterns
Benefits of Ports & Adapters Pattern
blog - Transactional Outbox Pattern
bounded context shared kernel
bounded contexts context map
builder design pattern
CAP Theorem
chain of responsibility design pattern
change amplification
classitis
code reading workshop
cognitive load
cohesion and coupling
command design pattern
common distributed system patterns
Communication and Coordination
Complexity
Complexity In Software Design
conformist pattern
conjoined methods
consistency
consistency in databases
contention in distributed systems
Costs of Ports & Adapter Pattern
creational design patterns
Customer Reliability Engineering
Customer Reliability Engineering
customer-supplier
database dirty reads
database durability
database durability techniques
database engineering
database internals
database isolation levels
database lost updates
database non-repeatable reads
database phantom reads
database read phenomenas
database transaction
DDD - bounded context
DDD - domain abstraction
DDD - domain activities
DDD - domain objects
DDD - hexagonal architecture
decorator design pattern
deep modules
dependancy inversion
design patterns
designing reactive distributed systems
DevOps Vs SRE
dispatcher
distributed systems
distributed systems - async communication
distributed systems - communication styles
Distributed Systems - Design Patterns for Event-Driven Architecture
docker
Docker Basics
Docker Security
domain driven design
Domain Driven Design a Practical Guide
dual write problem
encapsulation
error budget
event-based communication
eventual consistency
facade design pattern
factory design pattern
file storage vs object storage
fleeting notes from software-design tag
general purpose module
Go Lang
Go Lang - doc.go
Go Lang - Functional Option Pattern
Go lang - Modules
Go Lang - Rules of A Go Package
Go Lang - Variadic Functions
GoLang - Arrays and Slices
GoLang - constants
GoLang - Idiomatic Naming Conventions
GoLang - primitive types
GoLang - useful resources
gunther's universal law
Hexagonal Architecture & CQRS
Hexagonal Architecture Actor
Hexagonal Architecture Adapter
Hexagonal Architecture and DDD anti-corruption layer
Hexagonal Architecture Application, Core or System
Hexagonal Architecture Elements
Hexagonal Architecture Explained
Hexagonal Architecture Glossary
Hexagonal Architecture Interactor
Hexagonal Architecture Interface
Hexagonal Architecture Port
Hexagonal Architecture vs Clean Architecture
horizontal scaling
How Hexagonal Architecture is Related to DDD
how SLOs help balance operational and project work
how SLOs help build features faster
how SLOs help businesses make decisions
how to prevent information leakage
how to set SLOs for SLIs
in-sync replica set
inheritance
interface segregation
intro to platform engineering
inversion of control
iterator design pattern
kafka
kafka common terms
kafka consumer group
kafka high water mark
kafka in-sync replicas
kafka topic partitions
kafka use cases
kafka workflow as a pub-sub
kafka workflow as a queue
key characteristics of distributed systems
Kubernetes
Kubernetes - pods - arguments and commands
Kubernetes - configMaps
Kubernetes - env variables
Kubernetes - Master vs Worker Nodes
Kubernetes - Node Affinity
Kubernetes - Node Selectors
Kubernetes - replication controller and replicaSets
Kubernetes - Resource Requirements
Kubernetes - secrets
Kubernetes - security contexts
Kubernetes - Service Accounts
Kubernetes - Taints and Tolerations
Kubernetes Architecture
Kubernetes Cluster
Kubernetes Commands
Kubernetes Components
Kubernetes Components 1
Kubernetes Configuration
Kubernetes deployments
Kubernetes Namespaces
Kubernetes Node
Kubernetes Pod
Kubernetes scheduler
Kubernetes YAML Definition Files
laws of scalability
lddd - analyzing business domains
lddd - bounded context ownership boundaries
lddd - bounded context physical boundaries
lddd - bounded context vs subdomains
lddd - bounded contexts in real life
lddd - building boundaries with bounded context
lddd - business problem discovery
lddd - communication
lddd - comparing subdomains
lddd - converting business domain to a model
lddd - core subdomain
lddd - discovering domain knowledge
lddd - effective modeling
lddd - generic subdomain
lddd - identifying subdomain boundaries
lddd - implementing simple business logic
lddd - inconsistent models
lddd - integrating bounded context with cooperation pattern
lddd - integrating bounded context with customer-supplier pattern
lddd - integrating bounded context with separate-ways or duplication
lddd - integrating bounded contexts
lddd - integrating bounded contexts with anticorruption layer
lddd - integrating bounded contexts with conformist pattern
lddd - integrating bounded contexts with open-host service
lddd - integrating bounded contexts with partnership
lddd - knowledge discovery
lddd - managing domain complexity
lddd - model boundaries
lddd - modeling the business domain
lddd - scope of a bounded context
lddd - semantic domains
lddd - size of a bounded context
lddd - subdomain
lddd - subdomains as coherent use cases
lddd - supporting subdomain
lddd - tackling complex business logic
lddd - types of subdomains
lddd - ubiquitous language
lddd - ubiquitous language refined
lddd - using the ubiquitous language
lddd - what is a bounded context?
lddd - what is a model
lddd - who are the domain experts
learning domain driven design
linear scalability
liskove substation
Managing Kubernetes secrets with vault
message queueing
Microservice Patterns
mindmap - A Philosophy Of Software Design - POSD
mindmap - learning domain driven design
modular design
module abstraction
module implementation
module interface
monitoring
object oriented design
observability
observer design pattern
open-closed
outbox pattern
Outbox Pattern vs Two-Phase Commit
partition tolerance
pass-through methods
pass-through variables
philosophy of software design
PHP
PHP - ArrayObject
PHP - attributes
PHP - class constant
PHP - readonly
platform engineering
Pod YAML Definition
polymorphism
POSD - better together or better apart
POSD - Bring Modules Together If
POSD - causes of complexity
POSD - change amplification
POSD - choosing names
POSD - Classitis
POSD - Code Repetition
POSD - Cognitive Load
POSD - comments get out of date
POSD - comments might be worthless
POSD - complexity in software design
POSD - complexity is incremental
POSD - conjoined methods
POSD - consistency
POSD - could be more obvious
POSD - deep modules
POSD - define errors out of existence
POSD - dependencies
POSD - design it twice
POSD - different layer different abstraction
POSD - fighting against complexity
POSD - general purpose modules vs special purpose modules
POSD - higher-level comments
POSD - how to prevent information leakage
POSD - how to write better comments
POSD - how to write better comments - don't repeat the code
POSD - how to write better comments - pick conventions
POSD - i don't have time to write comments
POSD - implementation comments
POSD - information hiding
POSD - information hiding and information leakage
POSD - information leakage
POSD - information leakage types
POSD - interface comments
POSD - low-level comments
POSD - modifying existing code
POSD - Modular Design
POSD - module abstraction
POSD - Module Division and Complexity
POSD - module interface
POSD - modules should be deep
POSD - names should be consistent
POSD - names should be precise
POSD - obscurity
POSD - pull complexity downwards
POSD - separate general-purpose and special-purpose code
POSD - Splitting and Joining Methods
POSD - strategic programming
POSD - strategic vs tactical programming
POSD - symptoms of complexity
POSD - tactical programming
POSD - temporal decomposition
POSD - the myth of good code is self-documented
POSD - When is interface duplication okay?
POSD - why write comments
POSD - write comments first
prototype design pattern
publish-subscribe
reactive distributed systems
reactive principles
Resiliency
scalability
scalability vs performance
separation of concerns
setting up neovim
shallow modules
single responsibility
singleton design pattern
Site Reliability Engineering
SLAs
SLIs
SLOs
software design red flags
SOLID
special purpose module
state design pattern
strategy design pattern
strong consistency
structural design patterns
tactical tornado
targeting reliability
template method design pattern
the effect of coherency delay
the happiness test
the kano model
the reactive manifesto
Tmux
Toolbox
transaction script pattern
transactional outbox pattern
types of distributed systems architectures
TypeScript
TypeScript - Enum
TypeScript - Numbers
TypeScript - Type Annotations and Type Inference
TypeScript - Types and Type System
unknown unknowns
use different git email based on repository path
vertical scaling
visitor design pattern
what is a messaging system?
what is new in PHP 8.0
what is new in PHP 8.1
what is new in PHP 8.2
what is new in PHP 8.3
Why Code Comments Is More Important Than You Think
why reactive
zero tolerance
zooKeeper
README
Home
❯
zettelkasten
❯
technical
❯
lddd - converting business domain to a model
lddd - converting business domain to a model
Nov 20, 2024
1 min read
book-notes
ddd
lddd - what is a model
lddd - effective modeling
lddd - modeling the business domain
Graph View
Table of Contents
lddd - what is a model
lddd - effective modeling
lddd - modeling the business domain
Backlinks
lddd - discovering domain knowledge