Embarking on a complex project necessitates comprehensive context gathering while simultaneously approaching domain knowledge from a fresh perspective, leveraging domain expert insights. This approach aligns the technical team with business objectives and establishes a foundational roadmap for informed decision-making throughout the product lifecycle.
Initial knowledge-gathering sessions with the previous team and current application users proved unproductive. We briefly considered proceeding independently, despite the inherent risks.
As tech lead, I championed a domain-driven approach from the outset, given the project's complexity and the team's need for ownership. This centered the domain, fostering a shared understanding (ubiquitous language) that streamlined communication and facilitated mapping the application's current state.
We initiated EventStorming sessions using a Miro template, providing structure and a legend for effective focus. Prior familiarity with EventStorming concepts, either through pre-session preparation or initial explanations, is highly beneficial.
Our structured EventStorming process comprised:
EventStorming provided not only domain understanding but also a foundation for applying Domain-Driven Design (DDD) principles strategically and tactically.
A crucial initial step involved strategically structuring the domain. The system's complexity and the need for technical/business alignment led to adopting DDD principles. Context Mapping proved invaluable, even within our monolith awaiting refactoring. We identified Bounded Contexts, operating within a single technical context with a shared kernel. This analysis, while not deeply explored, guided the project toward a domain-oriented architecture, improving both technical development and cross-team collaboration.
Identifying Bounded Contexts clarified inter-system and external system relationships, simplifying complexity and establishing a foundation for future modularization. These initial decisions will guide the monolith's decomposition into manageable components aligned with defined contexts. This also facilitated prioritization and identification of areas for simplification, decoupling, or elimination. We focused on implementing Anti-Corruption Layers (ACL) for external system interaction, preserving system integrity.
Five key contexts were identified:
These decisions fostered sustainable architecture and aligned development with business needs.
Establishing a robust ubiquitous language proved vital. The benefits of a shared language, created through collaboration between domain experts and developers, far outweigh translation efforts or misinterpretations. This living resource connected the technical team with domain experts, improving communication, reducing misunderstandings, and ensuring accurate domain representation in the code. This fostered efficient, business-aligned technical solutions.
Following the strategic framework, we implemented tactical DDD principles to structure the code, reflecting domain reality and ensuring long-term sustainability.
Understanding the distinction between Entities and Value Objects is crucial.
Entities possess a unique, persistent identity, even with attribute changes. Examples include:
Value Objects lack individual identity; their value defines them. Identical attributes signify equivalence. They are immutable and ideal for encapsulating concepts appearing across the domain. Examples include:
This approach created more understandable and modular code with clearly defined responsibilities.
Example Value Object:
<code class="language-php"><?php
readonly class ProductEan13
{
public string $value;
public function __construct(string $value)
{
$pattern = '/^\d{13}$/';
if (!preg_match($pattern, $value)) {
throw new \Exception('Invalid product Ean13');
}
$this->value = $value;
}
}</code>Services are categorized by purpose and implemented patterns.
Domain Services encapsulate business logic not fitting into entities or values, operating strictly within domain rules without infrastructure dependencies.
<code class="language-php"><?php
readonly class ProductEan13
{
public string $value;
public function __construct(string $value)
{
$pattern = '/^\d{13}$/';
if (!preg_match($pattern, $value)) {
throw new \Exception('Invalid product Ean13');
}
$this->value = $value;
}
}</code>Application Services coordinate domain operations with external interactions, centralizing complex operations and separating domain and infrastructure. These include Use Cases, Command Handlers, and Event Handlers.
Infrastructure Services handle external component interactions (databases, file systems, etc.), acting as adapters to maintain domain agnosticism.
<code class="language-php"><?php
class CheapestCarrierGetter
{
public function get(
DeliveryOptionCarrierCollection $deliveryOptionCarriers,
Weight $orderWeight,
Country $country,
PostalCode $postalCode,
bool $isCashOnDelivery = false,
): Carrier {
// Logic to get the cheapest carrier
}
}</code>Services are classified by function and associated design patterns: Transformers, Builders, Factories, Presenters, Notifiers, Validators, and Clients.
This initial domain modeling, though incomplete and iterative, fostered team participation and commitment. Further refinement and restructuring were anticipated.
Recommended DDD resources:
DDD adoption paralleled team formation, following Tuckman's stages (Forming, Storming, Norming, Performing).
Initial team members reviewed the project, documented operations, and established technical and organizational foundations (processes, standards, tools).
Minor disagreements led to defining working styles, communication methods, and decision-making processes.
Team agreements, coding standards, development processes, WIP limits, deployment rules, technical debt management, and ADRs were established.
The established framework enabled efficient product development, prioritizing valuable initiatives, and fostering a culture of continuous improvement.
Documentation was managed using GitLab Pages and Jekyll with the Just the Docs theme, following the Diátaxis model: Tutorials, Guides, Explanations, and References. Automating documentation using Event Catalog and AsyncAPI was planned but not fully implemented.
The above is the detailed content of Understanding the Domain and Building the Team: The Foundations of Change (II). For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
