Lab Session 4 Software Design Architecture

Software Design Architectue:

Lab Session : 04

Exercise Questions:

1. Define a set of domain concepts and terminology that will form the ubiquitous language for your e-commerce
platform. Include terms related to products, orders, customers, and any other relevant domain concepts.

public class Order {

private String orderId;

private List<OrderItem> orderItems;

private ShippingAddress shippingAddress;

// Constructors, getters, and setters

public void addItem(OrderItem item) {

// Add item to the order

public void removeItem(OrderItem item) {

// Remove item from the order

// Other business methods and validations

public class OrderItem {

private String productId;

private int quantity;

private BigDecimal price;

// Constructors, getters, and setters

// Other business methods and validations

1|Page
 Lab Session 4 Software Design Architecture

public class ShippingAddress {

private String addressLine1;

private String addressLine2;

private String city;

private String state;

private String postalCode;

// Constructors, getters, and setters

// Other business methods and validations

2. Identify and define at least two bounded contexts within your e-commerce platform. Describe the scope and
purpose of each bounded context, along with the domain concepts and terminology specific to each context.

1. Order Management Bounded Context:

o Scope and Purpose:
 The Order Management bounded context focuses on handling everything related to
customer orders. It encompasses the entire order lifecycle, from creation to fulfillment.
 Its purpose is to manage order processing efficiently, ensuring accurate inventory
updates, payment handling, and timely delivery.
o Domain Concepts and Terminology:
 Order: Represents a customer’s request to purchase one or more products.
 Order Item: Refers to individual items within an order (e.g., specific products,
quantities).
 Order Status: Tracks the current state of an order (e.g., pending, shipped, delivered).
 Payment Transaction: Manages payment processing for orders.
 Shipping Address: Contains details about where the order should be delivered.
 Inventory Reservation: Ensures that ordered items are reserved in stock.
o Java Code Structure (Classes, Methods, and Attributes):

Java

// Order class
public class Order {
private String orderId;
private List<OrderItem> orderItems;
private OrderStatus status;
private Customer customer;
// Other attributes and methods...
}

2|Page
 Lab Session 4 Software Design Architecture

// OrderItem class
public class OrderItem {
private String productId;
private int quantity;
// Other attributes and methods...
}

// OrderStatus enum
public enum OrderStatus {
PENDING, SHIPPED, DELIVERED;
}

// PaymentTransaction class
public class PaymentTransaction {
private String transactionId;
private double amount;
// Other attributes and methods...
}

// ShippingAddress class
public class ShippingAddress {
private String addressLine1;
private String addressLine2;
private String city;
private String postalCode;
// Other attributes and methods...
}

2. Inventory Management Bounded Context:

o Scope and Purpose:
 The Inventory Management bounded context handles inventory-related operations.
 Its purpose is to maintain accurate stock levels, track product availability, and handle
inventory adjustments.
o Domain Concepts and Terminology:
 Product: Represents an item available for sale.
 Stock: Refers to the quantity of a product available in inventory.
 Stock Adjustment: Records changes to stock levels (e.g., restocking, sales).
 Reorder Point: Minimum stock level triggering a reorder.
 Supplier: Provides products to replenish inventory.
o Java Code Structure (Classes, Methods, and Attributes):

Java

// Product class
public class Product {
private String productId;
private String name;
private double price;
// Other attributes and methods...
}

// Stock class
public class Stock {
private String productId;
private int quantity;

3|Page
 Lab Session 4 Software Design Architecture

// Other attributes and methods...

}

// StockAdjustment class
public class StockAdjustment {
private String adjustmentId;
private String reason;
private int quantityChange;
// Other attributes and methods...
}

// ReorderPoint class
public class ReorderPoint {
private String productId;
private int minimumQuantity;
// Other attributes and methods...
}

// Supplier class
public class Supplier {
private String supplierId;
private String name;
// Other attributes and methods...
}
3. Develop a simple domain model for the core functionality of the e-commerce platform. This should include
entities, value objects, and relationships between them. Use the ubiquitous language defined earlier to ensure
consistency and clarity in your domain model.

public class Customer {

private String customerId;

private String name;

private String email;

private Address shippingAddress;

// Constructors, getters, and setters

public class Product {

private String productId;

private String name;

private String description;

private BigDecimal price;

private int stockQuantity;

// Constructors, getters, and setters

public class OrderItem {

4|Page
 Lab Session 4 Software Design Architecture

private String productId;

private int quantity;

private BigDecimal subtotal;

// Constructors, getters, and setters

public class Address {

private String street;

private String city;

private String postalCode;

private String country;

// Constructors, getters, and setters

public class Order {

private String orderId;

private List<OrderItem> orderItems;

private Address shippingAddress;

// Constructors, getters, and setters

public void addItem(OrderItem item) {

// Add item to the order

public void removeItem(OrderItem item) {

// Remove item from the order

// Other business methods and validations

4. Define explicit contextual boundaries between different parts of your system, including bounded contexts,
modules, aggregates, and services. Explain why each boundary is necessary and how it helps manage
complexity and promote modularity.

5|Page
 Lab Session 4 Software Design Architecture

ORDER MANAGEMANT MODULE:

// Order class

public class Order {

private String orderId;

private List<OrderItem> orderItems;

private OrderStatus status;

private Customer customer;

// Other attributes and methods...

// OrderItem class

public class OrderItem {

private String productId;

private int quantity;

// Other attributes and methods...

// OrderStatus enum

public enum OrderStatus {

PENDING, SHIPPED, DELIVERED;

// PaymentTransaction class

public class PaymentTransaction {

private String transactionId;

private double amount;

// Other attributes and methods...

// ShippingAddress class

6|Page
 Lab Session 4 Software Design Architecture

public class ShippingAddress {

private String addressLine1;

private String addressLine2;

private String city;

private String postalCode;

// Other attributes and methods...

Inventory Management:

// Product class

public class Product {

private String productId;

private String name;

private double price;

// Other attributes and methods...

// Stock class

public class Stock {

private String productId;

private int quantity;

// Other attributes and methods...

// StockAdjustment class

public class StockAdjustment {

private String adjustmentId;

private String reason;

private int quantityChange;

// Other attributes and methods...

7|Page
 Lab Session 4 Software Design Architecture

// ReorderPoint class

public class ReorderPoint {

private String productId;

private int minimumQuantity;

// Other attributes and methods...

// Supplier class

public class Supplier {

private String supplierId;

private String name;

// Other attributes and methods...

5. Describe strategies for ensuring continuous collaboration with domain experts throughout the development
process. How will you involve domain experts in refining requirements, validating the domain model, and
providing feedback on the evolving software solution?

Here are some strategies to ensure continuous collaboration:

 Early Involvement:
o Start Early: Engage domain experts from the project’s inception. Involve them during requirement
gathering, analysis, and design phases.
o Joint Workshops: Conduct joint workshops or brainstorming sessions to elicit requirements.
Encourage domain experts to share their insights, pain points, and vision.
 Shared Language and Concepts:
o Ubiquitous Language: Establish a common language between developers and domain experts. Use
domain-specific terminology consistently in code, documentation, and discussions.
o Domain Glossary: Create a domain glossary that defines key terms. Regularly review and update it
with input from domain experts.
 Collaborative Modeling:
o Domain-Driven Design (DDD): Apply DDD principles to create a shared understanding of the
domain. Collaborate on domain models, aggregates, and entities.
o Event Storming: Organize event storming sessions with domain experts to visualize domain events,
commands, and aggregates.
 Feedback Loops:
o Iterative Feedback: Involve domain experts in each iteration. Regularly demonstrate working
software and gather feedback.
o User Acceptance Testing (UAT): Collaborate on UAT scenarios. Let domain experts validate
features against real-world use cases.
 Domain Expert as Product Owner:

8|Page
 Lab Session 4 Software Design Architecture

o Product Ownership: Assign a domain expert as the product owner or a key

stakeholder. They can prioritize features, refine the backlog, and provide direction.
o Daily Standups: Include domain experts in daily standup meetings to keep them informed and
address any blockers.
 Continuous Communication Channels:
o Slack Channels or Chat Groups: Create dedicated channels for domain discussions. Encourage
domain experts to participate actively.
o Regular Meetings: Schedule regular catch-up meetings or demos. Discuss progress, challenges, and
upcoming features.
 Domain-Driven Testing:
o Collaborative Test Design: Work with domain experts to define acceptance criteria. Involve them in
writing test cases.
o Exploratory Testing: Encourage domain experts to explore the application and provide feedback.
 Feedback Mechanisms:
o Surveys and Questionnaires: Periodically gather feedback through surveys. Ask about usability,
feature satisfaction, and pain points.
o Feedback Forms: Include a feedback form within the application itself.
 Conflict Resolution:
o Open Dialogue: Encourage constructive dialogue where each member feels heard.
o Conflict Protocols: Establish clear conflict resolution protocols to address disputes systematically.
 Culture of Continuous Improvement:
o Retrospectives: Conduct regular retrospectives with domain experts. Discuss what went well, what
could be improved, and action items.
o Adaptability: Be open to adjusting processes based on domain expert feedback.

9|Page