Learning DDD initial attempt, from the most basic start, Business, divided bounded context model

Conference Business Profile

Conference is a system that provides an online booking create a meeting and conference seating platform. Users of this system there are two types:
1: Customers can create and manage meetings.
2: Conference seat reservation who can reserve conference seats.
Specific business-critical described as follows:
1. Client login, customers can create a conference, meeting and input basic information, such as name, time, place, number of participants and so on.
2. Customer-defined type seat of a meeting, you can define multiple, contains information for each type of seat are: name, seat price, number of seats, seat number is automatically generated according to the type of seat.
3. Publish or unpublish a client meeting, when a conference publication, subscribers can book a seat online meetings; if unpublished, the meeting of subscribers is not visible.
4. subscribers at the time of booking a seat conference, will generate orders, order needs to be paid to take effect.
5. order generation, subscribers can have 15 minutes to pay, over 15 minutes, orders for a reserved seat will recover, allowing other people to book.
6. After booking who successfully made a reservation, you can specify the actual participant information for each seat;
7. Customer (Owner conference) can manage each conference he created all orders, for example, you can see all the orders of the meeting and participant information to facilitate contact participant;



This case is a total of soup Conference case, case Address: https://www.cnblogs.com/netfocus/p/4591407.html , Case Source Address: https://github.com/tangxuehua/Conference
this case is the total soup blog, here are some small changes, because the front RBAC permissions to write a simple small DEMO, may come into the previously all basically needs to get the direct construction of the table, development, very little analysis, for the first time the real, which I hope that we can point out the shortcomings, communicate together.
This case will later write Demo, from the most basic plan to start, because there will be harvest in the process of writing with a problem to solve, is better than not to try a good, seemingly simple things, a will to practice found difficulties, it seems difficult things, whether to try to find that in fact is not difficult to imagine

Business processes in order, context demarcation

1. discovery business concepts, operational flowchart shown
2. Identification of business scenarios, depending on the role, the use case shown in FIG. (User stories), semantic relevance of the scene, as well as business relevance, scene classification (classification of the traffic Do not tangle too, can improve the analysis behind) bounded context
3. analysis of each business scenario, identify the participants in the scene, the basic characteristics of the participants, analysis of the interaction scenario, the business rules to identify the scene, analysis Effect of state change, such as (canceled meetings, invisible to the predetermined person), complex state: a state change can be considered a flowchart shown or otherwise process the expression changes, such as (change order status), identification the root of the polymer, the entity, the value of the object, service areas, art event
4. analysis of interaction between the embodiment and a plurality of scenes, and the impact generated during the interaction, indeed cooperative manner, to draw a map context, such as (Order and payment scenarios, after successful payment, notice orders, change state)


A: discovery business concepts, operational flowchart shown

二:找出业务场景,根据角色,画出用例图 (用户故事),根据场景的语义相关性,以及业务相关性,将场景归类 (将业务分类,不要太过于纠结,后面分析可以完善)限界上下文
业务场景:
1,客户创建会议 2,客户定义会议座位类型,生成座位号 3,客户发布会议 4,客户取消会议 5,预定者预定会议 6,生成订单 7,订单支付 8,指定座位参会人信息
用例图:


场景归类:

三:分析每一个业务场景,找出场景中的参与者 ,参与者的基本特征 ,分析场景中交互的过程,识别业务场景中的规则,分析状态变化的影响,比如(取消会议,对预定者不可见),状态比较复杂时:可以考虑画出状态变迁的流程图或者以其他方式表达出变化的过程,比如(订单状态的变化),识别出聚合根,实体,值对象 ,领域服务 ,领域事件

ConferenceContext



One: Creating Customer Conference
participants: customers, meetings, seat type, seat
customers Customer: Id, CustomerId, CustomerName, CustomerAddress, CustomerPassWord ( aggregate root)
Meeting Conference: Id, ConferenceName, ConferencePublishStatus, ConferenceStrartTime, ConferenceEndTime, ConferenceAddress, ConferenceContent, CustomerId , ConferenceParticipantNum, SeatTypeList (aggregate root)
rules:
1, the customer must log system, create a conference, the customer must exist in the system
II: customer-defined type seat
participants: customers, meetings, seat type, seat
seat type SeatType: Id, SeatTypeName, SeatTypePrice, SeatTypeNum, conferenceId, SeatList entity
seats seat: Id, SeatNumber, SeatTypeId entity
rules:
1, the number of customer-defined type of seat, can not exceed the number of participants of the meeting
2, seat number, the same type of seat even number, not allow duplicate numbers, the maximum number can not exceed the number of meeting participants
to interact and influence the process: after successful type seats, regulations Seat number is generated

三:客户发布会议,取消会议
参议者:客户 ,会议
作为会议的状态
规则:
3,客户没有定义座位类型,不能发布会议
4,发布会议,对预定者可见 ,取消会议,对预订者不可见
交互过程以及影响:发布会议后,会改变会议的状态为:已发布,对预定者可见,取消会议,会改变会议的状态为:未发布 ,对预订者不可见


预订者在预订会议座位,生成订单,订单需要进行支付才会生效
1,预定者,登陆会议系统
2,浏览已发布的会议
3,选择要预定的会议
4,选择要预定的会议座位类型
4,选择要预定的座位(可以选择多个座位)
5,点击提交,生成订单
6,系统处理订单
7,进入支付的页面,用户确认支付信息
8,用户点击确认支付,
9,系统处理支付,成功时:修改支付的状态为:已支付,发送一个事件通知订单,订单扣除会议座位,修改订单的状态为:支付订单成功
失败时:修改支付的状态为:支付失败,发送一个事件通知订单,修改订单的状态为:支付订单失败,回收会议座位
10,用户点击拒绝支付,修改支付的状态为:已拒绝,发送一个事件通知订单,订单回收会议座位,修改订单的状态为:拒绝支付
11,订单超过15分钟未支付,修改订单的状态为:支付已超时

ScheduledContext



Scheduled meeting seat, generate orders
participants: predetermined who orders, the order details, meeting, conference type seats, the seat meeting
a predetermined person (PredestineUser): Id, PredestineUserName, PredestineUserPhone, PredestineUserPassWord root polymerization
line (Order): Id, ConferenceId, PredestineUserId , OrderTotalPrice, CreateTime, OrderStatus, OrderItemList
order details (OrderItem) Id, OrderId, SeatId , SeatPrice
rules:
1, the state of the meeting must be published state
2, the order must contain an order detail information
3, the detection seat when booking a seat It has been selected
4, after booking, 15 minutes must be paid, expired recovery reserved seat

Status of the order:
1. generated orders (initialization state)
2. Intended seat success (successful reservation, withholding seat conference, scheduled recording time success, modify the order status: reserve a seat successfully)
3. The seat reservation failure (failure to book , modify the order status: failure to reserve a seat)
4. pay has timed out (orders to pay overtime, recycling conference seats, modify the order status as follows: payment has timed out)
5. payment orders success (net of conference seats, modify the order status as follows: payment orders success)
6. refused to pay (scheduled refused to pay, recycling conference seats, modify the order status is: refuse to pay)

PayContext



Payment Order
participants: orders, payments
paid (Pay): Id, OrderId, PayPrice, PayStatus, PayCreateTime aggregate root
payment details (PayItem): Id, PayId, SeatId, SeatPrice entity
rules:
authentication balance 1. Payment
status payment: 1, to be paid 2, payment of the successful 3, refused to pay 4, payment fails
interactive process:
1, the system processes the payment, success: modify the state paid for: paid, send an event notification orders, line deduction conference seats, edit orders the states are: payment orders successfully
failure: modify the state paid for: payment fails, send an event notification orders, orders recovered conference seats, modify the status of the order is: pay order failed
2, the user clicks refused to pay, modify the state paid is: rejected, send an event notification orders, order the recovery of conference seats, modify the order status is: refused to pay
3, orders for more than 15 minutes unpaid, modify the order of the state: to pay timed out

Participant information assigned seating actual
participants: Order, seats, participant
order seat (OrderSeat): Id, OrderId, ParticipantName, ParticipantPhone aggregate root



4. Analysis of interaction between the embodiment and a plurality of scenes, and the impact generated during the interaction, indeed cooperative manner, a context map shown, for example (after the order and payment scenarios, successful payment, order notification, change state)

Guess you like

Origin www.cnblogs.com/lifeng618/p/10967368.html
Recommended