[Lecture Topic Task] Explain how to project relates to The Life Cycle of a Domain Object emphasizing Guidlines Factories

[Adriana-Isabel]

In this task, I will apply principles from the “TheLifeCycleOfADomainObject” PowerPoint, focusing on Guidelines Factories to manage the creation of complex objects. These factories shift object creation outside the domain model and provide an interface that encapsulates the assembly process without relying on specific class references. By creating entire aggregates in one step, Guidelines Factories ensure that important rules and invariants are upheld. The goal is to focus on when and why to use factories, rather than the specifics of their implementation.

Additionally, repositories will manage persistent data like player information and game sessions, working alongside factories to ensure consistency across aggregates. A layered architecture will separate game logic from the frontend, promoting scalability and easier future changes. Strategic use of Guidelines Factories and repositories will improve flexibility, allowing the system to evolve without compromising the integrity of the domain model.

Score: 6 pts.

[Adriana-Isabel]

4.4.2 Guidelines Factories: We’re using Guidelines Factories to manage the complexity of building a multiplayer domino game, allowing players to compete against bots or friends.

• Factories separate concerns between back-end and front-end, making the system more flexible and scalable as the game evolves.
• On the front end, factories help create consistent UI components like player avatars and game boards, ensuring a smooth user experience.
• It handles setting up players, distributing tiles, and ensuring game states follow the rules, without cluttering core logic.
• Factories provide an interface that doesn’t rely on specific classes, making it easy to adapt both the back-end and front-end when new features or player types are introduced.
• They also enforce game rules and prevent invalid states, helping avoid bugs and keeping the game running smoothly.
• This approach ensures scalability and maintainability as we add features like bots and live multiplayer, ensuring a consistent experience across the system.

[Adriana-Isabel]

@AngelCIICMorales @Keiven-Soto @PinkSylvie

Hi, I finished my LTT. If there is anything that needs fixing, please let me know. Thank you.

[PinkSylvie]

Does what you write agree with the section beforehand? And how does what you write have to do with the creation of the aggregate as stated in the powerpoint? " factories create and reconstitute complex objects and aggregates" How does the factory ensure the invariants are satisfied? The things mentioned in the pwp about guideline factories were the following and I don't think what you wrote is quite related to it: – shift creation of complex object or aggregate to separate object, possibly without responsibility in domain model – provide interface encapsulating all complex assembly – interface does not require reference to concrete classes of the objects being instantiated – create entire aggregates in one piece ensuring their invariants – design of factories can use factory method, abstract factory, or builder – we’ll be concerned with when and why to use factories not with their implementation

[Adriana-Isabel]

Thank you for that. I'll edit it so it answers all of those questions and follows the feedback.

[Adriana-Isabel]

I took the feedback and decided to attacks the specific guidelines for factories that were highlighted. It presents a streamlined response that directly relates to the guidelines in the PowerPoint.

We’re using Guidelines Factories to manage the complexity of building a multiplayer domino game, allowing players to compete against bots or friends. In our project, factories separate the creation of complex objects, like players, tiles, and game states, from the domain model, following guidelines to keep the core logic focused solely on gameplay without additional responsibilities. Factories serve to encapsulate the entire assembly process, ensuring flexibility across both front-end and back-end, where changes can be made easily without needing to alter core classes.

Creation of Aggregates and Ensuring Invariants Factories create complete aggregates, such as a game-ready player setup or a fully distributed set of tiles, in one process, with each component validated to maintain the necessary game rules. This ensures that each aggregate follows game invariants, like having the right number of tiles or players initialized, before it’s passed to the core game logic, reducing the risk of errors.

Separation of Concerns and Encapsulation of Assembly Factories provide an interface that doesn’t require reference to specific classes, ensuring that complex assembly is encapsulated and adaptable. This allows the system to manage the creation of player avatars, game boards, or game states, supporting both new features and gameplay changes without altering the underlying architecture.

Scalability and Design Patterns To keep the system modular and extendable, we use factory patterns, including the factory method, abstract factory, and builder, focusing on when and why to use these patterns. This lets us add features, like bot players or live multiplayer modes, while keeping existing structures intact. By emphasizing these factory design principles, we maintain a scalable, maintainable system ready for future development.

[PinkSylvie]

You are listing what they do but not how. What are the examples of your bullet points?

[Adriana-Isabel]

4.4.2 Guidelines Factories

We’re using Guidelines Factories to manage the complexity of building a multiplayer domino game, allowing players to compete against bots or friends. This approach separates the setup of complex game objects, like players, tiles, and game states, from the core game logic. By moving object creation out of the domain model, we keep the main game code cleaner and focused only on gameplay.

Shifting Creation Responsibility Outside the Domain Model

Instead of having the main game logic handle details like setting up player profiles or distributing tiles, factories manage these details. For example, a Player Factory sets up a new player’s details, such as their avatar, score, and initial tile hand, ensuring consistency across all players. The main game logic simply requests a new player from the factory, avoiding the need to manage individual details and keeping responsibilities separate.

Creation of Aggregates and Ensuring Invariants

In our game, an aggregate refers to a whole set of related components needed to start gameplay—like all players, their tiles, and an initial game board state. The factory creates this complete setup at once, checking that game rules are followed (e.g., players each have the correct number of unique tiles, and the board state is ready for play). This centralized creation ensures all rules are respected upfront, maintaining game consistency and preventing errors that might occur if these elements were set up individually.

Encapsulation of Complex Assembly Through Interfaces

The factories use an interface to provide all the necessary game components without depending on specific details about each component. For instance, a Tile Factory produces the tiles needed for a game, whether they are standard or special tiles, without the main game logic needing to know which specific type of tile it’s working with. This makes it easy to adjust or extend tile types without affecting the core code, as the main game only interacts with the factory’s interface.

Scalability and Use of Design Patterns

To support scalability, we’ve designed factories using patterns that let us easily expand the game. For example, if we add new player types (like AI-controlled bots), we can adjust the factory to provide these without modifying the core gameplay code. This flexibility allows us to add features like bots or multiplayer expansions simply by adjusting or extending the existing factories, rather than reworking the main game structure.