Hunterlife224

• Cheat Sheet Recipes
• Ddd Cheat Sheet Pdf
• Ddd Cheat Sheet 2019
• Ddd Cheat Sheet 2020
• Ddd Cheat Sheet Printable
• Ddd Cheat Sheet Pdf
• Ddd Cheat Sheet 2020

Our first version, of our first cheat sheet! A quick one page guide on what you can do in combat, and calculating modifiers for attacks! GDB has a console GUI option available with the command line option -tui. Text console User Interface: gdb -tui Command just like regular GDB with a source screen showing source code and break points. My favorite gdb GUI is ddd. Awesome variable and memory interrogation. Dec 02, 2019 Domain-driven design (DDD) is an approach to software development for complex needs by connecting the implementation to an evolving model. Domain-driven design (DDD) Cheat Sheet List: Getting Started with Domain-Driven Design Download pdf Read more about Domain-driven design (DDD) on Wikipedia.

EventStorming is the smartest approach to collaborate beyond silo boundaries. The power of EventStorming comes from a diverse multi-disciplined group of people who, together, have a lot of wisdom and knowledge. While it originally was invented for a workshop to model domain-driven design aggregates, it now has a broader spectrum. From gaining a big-picture problem space of the whole domain to gaining insight into the entire software delivery flow and creating a long term planning. Every one of these workshops has the same basic requirements and needs. In this EventStorming cheat sheet post, I will describe these basic requirements in a cheat sheet.

I have moved the content of this blog to the DDD-crew GitHub page, were it will be updated by the community.

Preparations

Invites

Invites are essential to make it a successful workshop. You want to invite everyone who brings knowledge and who needs the knowledge, usually domain experts and the engineers. You want to add information about what the goal of the workshop is, and what EventStorming is. I always send the video Alberto Brandolini – 50,000 Orange Stickies Later to the attendees plus the resources page from eventstorming.com.

Materials

There is nothing so annoying as not having the right material, so you want to make absolutely sure you have everything needed. I have written a blog post here about it, go check it out!

Room setup

The best picture still is the one from the book EventStorming on leanpub. The idea is to have a modelling surface around 6-8 meters, a table for putting the materials on and a visible legend for people to see. We want to have no seats in sight. Also, you want a room preferable where the windows can open so you can have fresh oxygen in the room and have some food or candies lying around.

Facilitation

Cheat Sheet Recipes

For an effective EventStorming workshop, you want to have a dedicated facilitator.

As a facilitator:

• You want to have a neutral role so that you can cut long discussions short and visualise them with hotspots.
• You need to find to balance to when you will intervene and when you will let the discussion flow.
• You are always the first in the room and the last to leave, so you can set up the room correctly and talk with people afterwards.
• It is your job to facilitate the group and give them feedback and insights about the group interaction so that they can decide what to do. For instance, when you see multiple people looking on their phone, you can tell “I see that part of the group is distracted from the activity by looking on their phones”.
• You have to observe and let the group figure out what their needs are, however sometimes you need to decide for them when the group can’t.

Workshop process

Check-in

I always start a workshop with what is called a check-in. It is essential to be present physically and mentally for the workshop. So in a check-in, ask the attendees questions about how it is going with them. Like how was their weekend, how are they feeling, what do they hope to get out of the workshop today. You must not discuss any workshop or work-related stories. Always check-in first as a facilitator and lead by example by sharing just enough. Afterwards, let participants in the group decide for themselves when they will check-in popcorn style! When everyone is done, it is important to wrap up and summarise as a facilitator what you heard the participants say.

Agreements

Because we have a room full of people with different perspectives, it is vital to make some agreements on how we collaborate during the workshop. We want to make it explicit by writing this on a flip chart and stick it to a wall so that you as a facilitator can point to these explicitly. I write and discuss the following three agreements from Deep Democracy:

• Everyone is right; nobody has the monopoly on the truth
• We start a conversation to deepen our relationship
• We are willing to learn together

After you can discuss with the attendees if they themselves have rules they want to add and discuss these with them if they need to be added.

EventStorming

Now it is time to give an intro on EventStorming. I usually tell a microstory to the people explaining why classic forms of collaboration don’t work for me, and why EventStorming is different. These are personal and I advice you to figure out such a story for yourself. Explain the basics of what a domain event is on the legend.

Step 1: Chaotic exploration

Start with asking people to write their domain events that they know of for themselves. Here people must work by themselves so that we don’t bias each other. Also, try to avoid answering questions at this point. Tell them that they can put their domain events on the paper the way they feel is correct. We want their perception on the paper. Do not rush this part; this is the essential part of the whole EventStorming. When people start putting their domain events on they can begin to read each other’s events, but make sure they don’t begin discussing them out loud; it can bias or rush the others.

Step 2: Enforce the timeline

Ddd Cheat Sheet Pdf

After you are sure everyone is done with putting their domain events on the paper, we can start enforcing the timeline. It means asking the attendees to:

• Start discussing the events, I expect a lot of noise and chaos now.
• Removing duplicate events, let them discuss if they really are duplicate events, it might be the same language for different concepts.
• Ordering all events in the correct timeline.
• Adding structure with tape when needed, but be careful adding structure too soon. You can lose valuable insights from doing so.

Step 3: Hotspots

During Step 2 we will get a lot of conflicts between several perceptions, which is good. Out of conflict we grow and gain new insights. However, to be able to manage these conflict we add a pinkish sticky where there are conflicts. We call these hotspots. Hotspots can also mean pain points or questions that are unanswered. As a facilitator, you at this phase add the hotspots.

Ddd Cheat Sheet 2019

Step 4: Add concepts when needed

Ddd Cheat Sheet 2020

Whenever another EventStorming concept pop-up, we add them to the legend and introduce these to the group. The picture that explains “almost” everything are the concepts you can add:

Check-out

Like the check-in, we also want to end a workshop with a check-out. Stand in a circle with everyone and ask them what their thought was about the workshop. People can step inside the circle, give a statement and if other people agree they step with them inside the circle. Finish when you are sure everyone is done.

Remember, Alberto calls EventStorming like a pizza. The paper roll and domain events are the base of your pizza, the dough, but you put your ingredients on top of it the way you like it (as long as it isn’t pineapple 😉 ). If you want to learn more about EventStorming, or want to know how to facilitate EventStorming or want us to facilitate one of your workshops, feel free to contact me at kenny@baasie.com.

Also, this post is published on the Xebia blog site.

• DDD is an approach to data modeling
• Separating the quick-changing to ever-stable data
• 4 Layers
  • Infrastructure Layer = almost never change
  • Domain Layer = hardly change
  • Application Layer = could change frequently
  • Presentation Layer = changes all the time

Layers

• DDD mostly focus on crafting the domain layer
• Domain layer encapsulates all the domain logic

Ddd Cheat Sheet Printable

Domain vs. Application Layer

Ddd Cheat Sheet Pdf

• Domain logic = logical part of the business, i.e. the syntax of the business
• Application logic = the configurable part of the business, i.e. the semantics of the business
• The domain model is there to ensure the domain is legitimate, or, is syntactically correct
  • Example 1: When we put some goods to a spot in a warehouse, the spot should be empty; after we put the item in, the spot should be occupied; if someone else try to put another item in the same spot, it should not be denied
  • Example 2: In the domain of car plate registration, the plate number must always be unique, if someone try to register a plate that was already assigned to another car, the system should not allow it
  • Example 3: If I want to buy a ticket, the ticketing system should only issue a ticket after receiving the money
• Domain logic should look very simple and intuitive and should be the same for most people familiar or unfamiliar with it, because it is based on basic logic that rarely changes
• It should only cares about syntax but not semantics, as the latter could vary amongst different instances of the domain
  • Syntax error: two car plates had the same number; the balance between two parties in a successful transaction do not equal to zero; a ticket is issues without transaction attached to it; system shows that 100 items are at the exact same spot of a warehouse; price for an item is negative 5 dollars
  • Semantics error: a supermarket casher decide the shutdown the shop for half day; a visitor of a website can view the earnings of the site admin; someone won lottery 5 consecutive times
• In short, if a syntax error happens, something illogical / unphysical / impossible happens; if a semantics error happens, we may feel strange but still the business plays by rules
• Another example
  • There is a flight / business trip booking system
  • In Big Company A, only the boss can view where other people are going
  • In Startup B, everyone can see where everyone is going
  • They have very different semantics, people from one company with feel very strange about the other company, but the syntax stays the same
• As domain logic rarely changes, so when the syntax stays the same, we are in the same domain
• When the domain logic really change, it is highly possible that we have entered into a completely different domain
• Each company, organization, application could have different semantics, as how the domain model is manipulated, but the domain model stays the same
• More examples
  • HR service provides salary reports, one company allows only an employee to see his/her own salary report, another allows the employee and the boss, yet another allows everyone to see everyone; all in the same domain, same business logic, but different semantics
  • A car production line can be stopped by a button, in Toyota, everyone working on the line has the power to push the button, in Ford, only the boss has the authority; same syntax (push button > stop line), different semantics (who can do it)
  • In shop A, when you buy something, you get 1 credit for each dollar you spend, in shop B, you get 100 credit for each dollar you spend; same syntax, different semantics
• When we have different set of semantics, we basically have a different application
• That is the core difference between application and domain
• This makes domain very stable and reusable across applications sharing the same syntax

Other Layers

• Infrastructure = database, tables, message queues, basic components that could be reused in any domain and any application
• Presentation = how the data is displayed (presented), like Web page, themes, apps, etc.

Other Ideas

Ddd Cheat Sheet 2020

• Ubiquitous Language = When any members of the domain / on the team say “order”, we want to make sure everyone is referring to the exact same thing, so we clearly define a set of terms and use them throughout our data modeling
• Bounding Context = There are situations when different players in the same domain must use the same name for slightly different things, then we bound a term to a context
  • For example, when referring to a “customer”, a sales is thinking about the customer’s business problem, revenue, etc.; a technician is thinking about the customer’s architecture, software stack, engineer team structure; a support personnel is thinking about the support plan, last support situation, customer contact name, etc.
  • They all use “customer” and it is difficult to give a different name for each slight variation or perspective they have, so we bound the customer to SalesContext, EngineerContext and SupportContext and create models corresponding to those contexts.