EWS
今日要闻
宁德时代组织调整 曾毓群直管制造与采购；OpenAI 前首席科学家宣布成立新AI公司；尹烨不再担任华大基因副董事长；调改永辉首日营业额暴增14倍？永辉超市、胖东来回应；东方甄选自营品首次公布成绩单；绿茶餐厅第四次冲刺港交所；威马被判赔偿吉利约6.4亿元；银联云闪付能扫微信经营收款码了；苹果回应AI仅限iPhone15Pro系列：出于速度考虑而非营销套路……
头条
宁德时代架构调整，曾毓群靠近一线
据晚点LatePost报道，宁德时代上周宣布了一项新的组织架构与汇报关系调整。
调整之后，宁德时代现有的超40座工厂（分属六个大区），被整合为国内和海外两个大区，由原来的两名大区经理分别掌管，直接向宁德时代董事长曾毓群汇报。
而在此前，六个大区的经理是向宁德时代供应链与运营体系联席总裁冯春艳汇报，冯春艳再向曾毓群汇报。作为追随曾毓群多年的得力部下，冯春艳管理的生产制造运营也是宁德时代最核心的业务。此次架构调整之后，冯春艳继续另有重用，不过曾毓群将更直接地管理生产制造运营和采购等业务。
目前锂电行业竞争激烈，宁德时代虽然市场份额领先，但面临的压力不小。前几天宁德时代刚传出“奋斗100天”的新闻，即号召员工奋斗100天，每日早上8点上班、晚上9点下班，一周工作6天。后证实是一些部门领导下发的加班通知，并非针对全体员工。
无论公司，曾毓群借助架构调整更加靠近一线是事实，这可能也反应了“宁王”的某种竞争焦虑。
人物
OpenAI 前首席科学家宣布成立新AI公司
今天凌晨，OpenAI 前首席科学家 Ilya Sutskever 向外界透露了他的最新动态，宣布创立一家名为”安全超级智能”（Safe SuperIntelligence，简称 SSI）的新公司。五月中旬，Ilya 从 OpenAI 离职。SSI 公司的主要方向是开发安全、强大的通用人工智能（AGI）系统， Ilya 认为“这是我们这个时代最重要的技术问题”，公司短期内无意销售各种 AI 产品或服务。（第一财经）
尹烨不再担任华大基因副董事长
6月18日，华大基因公告称，因任期届满，公司第三届董事会副董事长尹烨将不再继续担任公司副董事长、非独立董事及审计委员会委员职务，但会继续担任公司部分控股子公司的董事。截至公告披露日，尹烨直接持有华大基因106.4万股。另据华大基因2023年度年报，尹烨出生于1979 年，还曾任华大基因总经理、华大控股首席运营官等职。（界面）
大公司
调改永辉首日营业额暴增14倍？永辉超市、胖东来回应
有消息称，截至6月19日22:26，永辉信万广场店调改后首日销售额达188万元，是调改之前日均销售额的13.9倍，客流达12926人。记者分别向永辉超市信万广场店和永辉超市证券部进行求证。永辉超市证券部工作人员告诉记者，公司层面不掌握这一数据，门店数据以门店公布为准。
永辉超市信万广场店表示，昨天开业以来人流量非常大，但是店面没有对外披露相关数据。此外，记者还向胖东来进行求证。胖东来回应称，相关数据以永辉超市披露为准。7月1日胖东来还要对永辉超市新乡店进行改造。(中证金牛座)
东方甄选自营品首次公布成绩单
6月19日，记者从东方甄选自营新品发布会上了解到，2024下半财年（2023年12月至2024年5月），东方甄选公司自营产品GMV（商品交易总额）突破36亿元，同比增长108%，环比增长74%。东方甄选于今年推出了包含床上用品类、服饰内衣类和纸品日用类等多类目在内的自营生活用品。截至目前，东方甄选自营产品总数超400款，其中八成是农产品，同期在售达260款。此外，公司自营产品总用户数超2500万，产品复购率达59%。（每日经济新闻）
绿茶餐厅第四次冲刺港交所
6月19日，港交所官网显示，绿茶餐厅再次向港交所递交招股书。这是绿茶餐厅时隔两年后重启香港IPO（首次公开募股），也是它第四次冲刺港交所。根据灼识咨询报告，2023年，在中国休闲中式餐厅品牌中，绿茶餐厅的门店数位列第三，收入位列第四。（新京报）
苹果回应AI仅限iPhone15Pro系列：出于速度考虑而非营销套路
上周苹果在 WWDC 2024 上推出全新的 AI 系统"Apple Intelligence"，并宣布将在今年秋季登陆 iPad、iPhone 和 Mac 平台。但目前苹果 AI 系统只能在iPhone 15 Pro 和 iPhone 15 Pro Max 上使用。苹果相关高管否认了限制 iPhone 15 Pro 系列是为了鼓励用户购买新款 iPhone 的营销策略。 其表示，大语言模型的推理计算量非常大。因此，这非常依赖于设备的带宽、NPU 规模，以及设备本身的性能，所以需要足够强的性能才能使这些模型跑出够看的速度。（第一财经）
威马被判赔偿吉利约6.4亿元
近日，最高人民法院知识产权法庭审结了吉利与威马的新能源汽车底盘技术秘密侵权纠纷上诉案，最高人民法院二审判决威马赔偿吉利经济损失及维权合理开支合计约6.4亿元，创我国知识产权侵权诉讼判赔数额历史新高。
时间追溯至2016年，吉利旗下的成都高原汽车工业有限公司有近40名高级管理人员及技术人员先后离职，其中大部分人员随后加入了威马及其关联公司。2018年，吉利发现这些离职人员中的部分人员以发明人的身份出现在威马及其关联公司的实用新型专利中。吉利认为，威马没有任何技术积累或合法技术来源的情况下，在短期内即推出威马EX系列型号电动汽车，涉嫌侵害吉利技术秘密。（证券日报）
投融资
嘀嗒出行：申请通过香港IPO发行3900万股股票
嘀嗒出行港交所公告，申请通过香港IPO发行3900万股股票。发行价指导区间为每股5-7港元。预计将于6月26日定价。预计股票将从6月28日开始交易。
健康险独角兽元保拟赴美上市，已敲定承销券商
近日，《健闻咨询》从多个渠道获悉，保险科技公司元保数科赴美上市取得新进展，目前已敲定高盛、摩根士丹利等多家证券承销商。元保成立于2019年，是一家互联网健康险公司，旗下的互联网保险中介平台元保于2020年正式上线运营。元保成立后，在不到一年的时间里完成了三轮融资，2021年5月又完成了近10亿元C轮融资。
近日，证监会国际合作司发布消息，元保已成功获得境外发行上市备案通知书。根据披露，元保数科计划发行不超过6450万股普通股，并即将在纳斯达克或纽约证券交易所上市。
新技术/产品/服务
银联云闪付能扫微信经营收款码了
业内关注的巨头支付互联互通再迎新进展。6月19日，记者获悉，继此前陆续开放个人收款码、商家码，以及小程序等场景在内的互通合作后，近日，银联网络再迎来微信支付经营收款码场景的全面接入。也就是说，消费者凡是在商户看到有微信收款码，均可用云闪付App实现扫码支付。（北京商报）
谷歌DeepMind开发新AI 可为视频生成配乐和对白
近日，Google的人工智能研究实验室DeepMind表示，它正在开发为视频生成配乐的人工智能技术。DeepMind在其官方博客上发表文章称，它认为V2A（”视频到音频"的缩写）技术是人工智能生成媒体拼图中必不可少的一部分。虽然包括DeepMind在内的许多机构已经开发出了视频生成人工智能模型，但这些模型无法在生成视频时同步生成音效。（财联社）
腾讯将在华为、OPPO、vivo等渠道停止更新《DNF》手游
围绕近期大热的《DNF》手游，腾讯或将与硬核联盟正面对决。6月19日，《地下城与勇士：起源》运营团队发布公告，称因合约到期，6月20日起，DNF手游将不再上架部分安卓平台的应用商店。21世纪经济报道记者从知情人士处独家获悉，腾讯已向“硬核联盟”中的华为、OPPO、vivo等三名成员发出通知，称在以上渠道的《DNF》手游包体均将停止更新。
*题图购买于视觉中国
去年、我整理了一篇名为《如何做架构设计？》的文章，主要探讨了架构设计的目标和过程，然而、那是一篇概括性的文章，用于启发思路，并不是具体的实践指南，因此、我一直期望给出具体参考案例。
我几乎忘了这件事，如今回顾、我发现并没有合适的案例可供参考，现有的案例要么不完整、要么是与业务耦合的特定场景，要么无法支撑研发落地。所以我决定从实际生活中出发，虚拟一个案例场景，以便能够系统性的阐述这个问题。
正文开始
本案例侧重于DDD的实践，从实际业务场景推导软件架构，将业务元素映射为系统元素，让系统本身成为最好的业务文档。在本案例中，我们选择餐厅作为业务场景，但不在意餐厅实现细节，而是以餐厅为主线故事，系统性的阐述DDD落地方法。希望读者能够从中吸取精华，去其糟粕，全文较长、耐心读完、必有收获。
1、领域设计
领域设计的核心是业务驱动的分而治之，旨在缩小软件系统与真实业务的差异，从而减少差异带来的问题。
当业务与系统之间存在差异时，我们无法将业务逻辑和程序逻辑对应起来，从而分不清区域，也分不清职责，因此会觉得混乱。就像你平时不会将枕头和被子放在厨房或卫生间一样，你的床上不会放着大米白面，否则你想睡觉是一件很复杂的事情，软件系统也是如此。
所以、首先要把业务分析清楚，然后设计与业务模型对应的软件模型，这就是DDD的核心思想。
1.1 宏观流程
假如我要设计一个餐厅，由于分而治之的需要，我会首先从宏观流程去分析，可以帮我们迅速找到重要的区域（这是功能相关性的初步划分）。
??
因此会得到几个明确的行为区域，我将餐厅划分为“菜品域”，“订单域”，“厨房域”，“用餐域”，这是宏观级别的领域划分，后续应该针对每个区域单独分析。
产出物是：宏观流程和参与角色
1.2 统一语言
语言贯穿于整个开发过程，从需求分析到设计、从设计到编码，因此好的语言非常重要，好的语言体现了清晰的业务概念。
在这个阶段，我们需要通过梳理，找到业务中都有哪些实体与行为，对其做一些归纳。我们的核心问题是“谁”通过什么“行为”影响了“谁”，其中的三个要素分别是“角色”、“行为”、“实体”，因此我的建议是先找到 “角色”、“行为”、“实体”，并对他们归类，我常常关注角色以及具体身份、行为以及包含的重要步骤、实体以及具体实例。
角色：是施事主语、是名词，是主动发起行为的一类实体。
行为：是动词、是做了什么事情，是行为本身。
实体：是名词，是除“角色”之外的其他实体。
推荐使用脑图画出来，我认为归纳后的脑图有助于我们识别根本要素，有利于抽象。
产出物是：名词、概念定义、相关脑图。
??
1.3 用例分析
在这一步、我们使用相对宏观的分析，不需要进入用例的细节分析，主要的目的是掌握角色与行为之间的关系，理清谁在做什么，角色的职责目的是什么，用于指导领域划分以及领域服务设计。
产出物：用例图
以做菜为例，如图
??
1.4 领域划分
我们在分析宏观流程时，划分了几个行为区域，那是宏观级别的。在那基础之上，我们需要拉进某个区域的视角，再结合之前的用例分析，按照“功能相关性”、“角色相关性”进一步划分领域。我们不仅要知道谁做了什么，还需要知道谁“在哪”做了什么。
功能相关性：也称为业务相关性，业务是由一套用例组成的，一套用例之间是符合高内聚原则的，一套用例构成了一个问题空间，也就构成了一个领域，所以“功能相关性”是划分领域的黄金标准。例如与做菜相关的用例都应该归属于厨房，所以我们确认了厨房域，这也是很自然的事。在这一步，通过划分领域、梳理领域与用例之间的关系。
角色相关性：角色相关性不可以作为首要参考因素，在特殊情况下用于划分子域，某个区域涉及多个角色参与，可以按照角色的分工，拆分为多个子域，从而满足不同角色的个性化需要。例如厨房的采购人员负责买菜、刀工负责切菜、大厨负责烹饪。我们就会考虑将厨房划分为“采购子域”、“加工子域”、“烹饪子域”。通常来说，子域不具备独立的问题空间，不会作为独立的领域存在。
划分领域的核心原则是保证领域的自治性（最小完备和自我履行），谨慎使用“实体相关性”划分领域，否则有可能将一个功能打散在多个领域上，违反了自治性原则，如果按照功能相关性划分，更容易实现领域的自治性，并且有助于将功能需要的实体聚合在一起。
产出物：领域、子域、领域与用例的关系
以厨房域为例，如图
??
在复杂业务时，可以使用事件风暴方法辅助分析，并输出上述产出物。
1.5 领域服务
什么是领域服务？一个领域可以有几个领域服务？ 我们如何划分领域服务？标准是什么？
我认为一个领域不只有一个领域服务，我们不应该按照实体划分，也不应该按照聚合划分，也不该按照功能相关性划分。
领域服务用于实现用例功能，我认为应该使用角色划分领域服务。在用例图中，不同的角色发起不一样的用例，不同的领域服务提供不一样的用例，只有这样、才能确保领域服务是用例图的映射，也才能真正体现业务含义。领域服务是面向角色的，在一个领域中、每个角色对应一个领域服务。另外、同一个用例的逻辑差异是与角色的身份有关的，角色的身份对应了服务的泛化，角色的用例对应了服务的方法。对于此观点、我们在后续功能设计的部分也有体现。
例如：厨房域（厨师服务、刀工服务、采购员服务），菜品域（客户服务、管理者服务）。
产出物：领域服务类图
??
1.6 领域建模
我们思考一下，到底什么才是领域驱动设计？ 例如“厨房域”被称为“菜域”，“厨师”的“做菜”功能被称为“菜服务”的“做菜”功能，也例如“菜品域”有个“菜品服务”，“菜品服务”提供了“增、删、改、查”的功能。我们往往以最核心的实体为中心，误以为业务就是在操作数据，丢掉了业务本质含义，逐渐也就走歪了。
不要学传统的数据模型驱动设计，实体模型驱动设计与前者的本质是一样的，是换汤不换药的，这不是技术问题，而是过度集中在实体上以至于忘记其他元素。我们必须把精力放在业务本身，防止领域驱动设计变成领域模型驱动设计。我们不应该优先思考领域模型，不应该以领域模型命名一切，不应该让领域模型决定业务的实现方式。厨房不只有菜，也有服务员和厨师，我们使用合适的语言对应合适的元素，以确保软件元素是真实业务的映射。例如“厨师在厨房做菜”，这句话中的所有元素都要在系统中得以保留，丢了一个也不行，更何况只剩下菜了。
所以、我们先做领域划分，再做领域服务设计，最后做领域建模，这个顺序很重要，可以避免我们错误的以领域建模为中心。先有用例才有领域，先有领域才为领域建模，实体是为了实现一组用例存在的。而一组用例不一定依赖实体。
回到正题、我们在这一步的重点还是菜的问题，我们分析实体与领域之间关系（领域聚合），实体与实体的关系（OO聚合）。其中OO关系影响了功能的扩展性，需要我们特别关注。实体因一套用例而聚合在一起，我推荐做法是将领域的用例放在一起分析，找到他们的共同性，充分考虑变化，使用兼容性更好的模型解决问题。
??
组合、聚合
聚合（aggregation）：聚合关系是一种弱的关系，整体和部分可以相互独立。
组合（composition）：组合关系是一种强的整体和部分的关系，整体和部分具有相同的生命周期。
可以使用如下案例，既能表达领域聚合，又能表达OO聚合的关系。
??
产出物：聚合、实体、值对象、实体的属性
1.7 领域上下游
领域上下游关系，不是领域的依赖关系，依赖关系指的是能力的依赖，是共用了某些能力。领域上下游关系，也不是调用关系，调用关系是与用例相关的，不是用于描述领域处境的。
领域上下游关系指的是影响力的关系，上游影响下游，影响力分为“逻辑影响”和“数据影响”，一般说来我们更应该关注“数据影响”，因为上下游的逻辑影响也是靠数据传递的，所以领域上下游关系是一种数据流向的限制，是业务发生的顺序限制，用于规定该领域所使用的数据，是下游领域依赖上游领域“准备就绪”的体现。合理的上下游限制，有助于减少领域之间的不必要依赖和重复的计算。
领域上下游是与场景相关的，并不是一成不变的，不同场景的情况下，存在不同的上下游关系，各场景应该独立说明。
产出物：各场景的上下游说明
例：在【菜品管理】场景下
如果厨房的某些食材不足了，或者某个厨师休假了，就会影响到菜品的展示，从而影响到客户的订单。
例：在【客户消费】场景下
??
客户的订单、影响厨房生产的菜，从而影响刀工的行为，也影响到了采购。
请对比下面两个图，用于理解领域的上下游
??
实际上，厨师不应该依赖采购人员的采购功能，也不依赖刀工的切菜功能，他只是依赖“初加工食材”而已，而“初加工食材”就是被处理好的数据，厨师在做饭时，“初加工食材”就已经被处理好了，上面的图例只是为了说明一个关于领域上下游的问题，这是业务发生顺序以及数据来源的问题。
我们常常使用领域事件串联业务流程，在使用领域事件时，不止要关注点对点的解耦，更应该使业务流程符合领域上下游限定，让各个领域独立运行。
顺序发生优于嵌套发生，数据依赖优于功能依赖。
2、架构设计
架构设计是为了解决软件系统复杂度带来的问题，找到系统中的元素并搞清楚他们之间关系。
架构的目标是用于管理复杂性、易变性和不确定性，以确保在长期的系统演化过程中，一部分架构的变化不会对其它部分产生不必要的负面影响。这样做可以确保业务和研发效率的敏捷，让应用的易变部分能够频繁地变化，对应用的其它部分的影响尽可能地小。
架构设计三原则：合适原则、简单原则、演化原则
2.1 分层架构
我们需要按照 接口层、领域层（领域用例层、领域模型层）、依赖层、基础层 构建架构模型。
接口层：为外部提供服务的入口，是适配层的北向网关。不实现任何业务逻辑，也不处理事务，是跨领域的，是流程编排层，是门面服务。
领域用例层：是领域服务层，是领域用例的实现层、隶属于某个领域、是业务逻辑层，是事务层，业务逻辑应该在这层完整体现，不要分散到其他层级。
领域模型层：是领域模型（实体、值对象、聚合）的所在位置，专注于领域模型自身的能力，不包含业务功能，可以处理事务，是原子化的能力，是领域对象的自我实现。
依赖层： 是连接外部服务的出口，是适配层的南向网关。包括仓储，端点、RPC等，主要作用是领域和外部解耦，是跨领域的。
基础层：与业务无关的，与领域无关的，通用的技术能力，技术组件等。
2.2 架构映射
架构的视角，从大到小依次是：系统->应用（微服务）->模块（包）->子模块 这样的从大到小的层级。
业务领域映射：我们将划分好的领域，按照对应的视角映射为对应的元素，领域模型映射到架构模型时，应该是视角对等的，如果餐厅是系统、那么厨房就是应用，如果餐厅是应用、那么厨房就是模块。也应该是层级匹配的，将用例的实现映射到用例层，将领域模型的实现映射到领域模型层。也应该是名称一致的，将领域名映射为应用名或包名，将实体名映射为实体类名，将角色名映射为领域服务类名，将角色身份名映射为服务类的子类名，将用例名映射为服务类的方法名。
技术和抽象问题：有时候、业务领域分析不能体现那些共性的技术问题，所以需要适当结合技术视角，可能需要对领域模型微调。同时、我们需要找到共同需要的基础能力，例如“水”、“电”、“煤气”等等，将这些作为额外的考虑因素，要做到业务问题与技术问题解耦，不要将技术问题和业务逻辑揉成一团。
领域设计，类似餐厅设计师，他设计餐厅有几个区域，区域的用途是什么。
架构设计，类似建筑设计师，他设计如何走水电煤气、如何施工等。
产出物：分层架构图
以厨房为视角，其架构如下
??
以餐厅为视角，其架构如下
??
分层架构图，体现逻辑上的层级分布，而不是代表组件的具体含义，组件是应用还是模块、需要结合实际情况而定。
2.3 必要的约束
1、分层架构越往下层就越是稳定的：下层是被上层依赖的，下层不可以反向依赖上层（扩展点除外）。因为分层架构的核心原则是将容易变化的逻辑上浮，将共性的、原子化的、通用的逻辑下沉，被依赖的下层应该是稳定的，这要求上层承接更多业务变化。下层离开上层应该是可以独立存在的，例如在接口层定义的DTO不可以在下层被使用，但领域层定义的实体可以被上层使用。
2、在使用充血模型时，应该符合面向对象编程原则：不要随意的将一些能力都充到领域实体模型中。以“菜”为例，重量和规格是“菜”的自身的属性，激发味蕾是“菜”的能力，“菜”可以维护自身的持久化状态。但是、请注意、“菜”不可以“炒菜”，因为“炒菜”的时候，“菜”还没有出现呢，“菜”不是自己的上帝，“菜”需要被做出来，所以“菜”被做出来之前是没有“菜”的，这是个时间上的概念，不要错把“炒菜”的能力放在“菜”的身上。“炒菜”用到的“水+电+气+食材+调料+厨具”不应该是“菜”的属性范围，这些元素都在“厨房”的范围中，不要让领域的模型包含不属于自身的元素，领域的实体模型只是领域的一部分，只用于实现通用的模型能力。
3、接口层和依赖层是与领域无关的：他们是与技术相关的层级，不属于任何领域，这两层不能包含业务逻辑。有时候我们可以把接口层拆为两层（接口层、应用层），但是我不建议这样做，我们没有必要把很轻的一层再次拆分。我们也可以把依赖层拆分为两个（领域模型依赖、其他依赖），我非常建议这样做，因为领域模型依赖的资源不会被其他领域使用，拆开之后可以有效限制领域模型的依赖，
4、领域层是与环境无关的：无论某个领域是应用还是模块，都应该是完整的。应该具备独立的用例层和独立的模型层，即使多个领域在同一个应用当中，也要按照他们是分别独立去看待，无论某个领域是应用还是模块，领域对外部的交互，不可以绕过依赖层和接口层。
5、领域应该自治性的：把一个领域拆分为子域、子子域..... 无限拆分，子域就不完整了。或者没有按照功能相关性拆分，也可能破坏领域的完整性，不完整的领域不符合自治性原则。所以、不完整的领域不会单独存在，所以、当一个领域的内部子域不具备独立性时，子域之间不必严格解耦，不需要通过依赖层访问本领域的其他子域，他们之间可以直接调用。
6、领域用例层和领域模型层是两个层级：领域用例层指的就是领域服务层，不建议将领域服务与领域模型放在同一层，这可能会导致逻辑的分散（一部分在领域服务层、一部分在领域模型层）。如果将业务逻辑写在领域模型中，会导致业务逻辑进一步下沉，业务逻辑的不确定性太大，是不适合下沉的，是违反分层架构原则的。领域模型对应的是实体、领域服务对应的是用例，分开就是更有效的限制措施。
7、领域用例层只能承接符合自身领域的用例：我们划分出领域的目的，就是为了区分每个领域的职责所在，因此他们必须严格按照职责办事，我们在之前已明确了用例和领域之间的关系，需要严格遵守。 如果出现跨领域的编排，请在接口层串联。如果依赖其他领域的功能，请把被依赖的功能逻辑放在其他领域中。
8、领域模型层遵循最小依赖原则：只可以依赖必要的资源，必要资源指的是领域模型实现自身能力需要的资源，不包括实现业务逻辑依赖的资源。例如领域模型需要依赖DB完成持久化，可以依赖数据访问资源，但不应该依赖其他领域资源、不可以依赖RPC资源等。 最好的做法就是将领域模型依赖的资源单独拿出来，并且与领域模型放在一起。保持领域模型层的独立性，在多个领域应用共享领域模型时，方便使用共享内核的设计模式。
2.4 微服务划分
服务划分以领域划分为参考，主要看我们要拆分到什么粒度，不建议将几个领域放在同一个服务中，不建议把一个完整的领域拆分为几个不完整的微服务。
产出物：微服务
例如餐厅：是有必要拆分的，餐厅的“菜品域”，“订单域”，“厨房域”有独立的问题空间，是具备自治性的。
例如厨房：是没有必要拆分的，厨师与刀工的耦合非常高，他们都在做饭，分开之后是不完整的，分开就是没有必要的。
所以餐厅被拆分为：厨房、菜品、订单，三个微服务。基于此、我们单独拿出餐厅门面服务作为接口层应用，再单独拿出餐厅基础服务作为水电煤气的应用。
一般情况下，依赖层不会作为单独的服务提供，会被以组件的形式嵌入到其他服务中。
??
3、功能设计（用例实现）
如果说领域设计是餐厅的设计师、架构设计是餐厅的建筑师、那么功能设计就是餐厅的厨师。
任何设计都要落地到功能设计，如果厨师不守规则，偏偏要去洗手间洗菜，最后的结果依然是一团乱，最终会导致前面的所有设计泡汤。
功能设计是实现 “面向扩展开放、面向修改关闭” 的途径，
功能设计是为研发提供的落地支撑。
3.1 功能的概念
功能迭代时，功能会发生一些变化，所以他的含义是可能变化的，所以我们需要再次审视功能的概念，及时加以调整。
例如、我们实现了一个“做蛋炒饭”的功能，后来又实现了一个“做辣椒炒蛋”的功能，那么我们应该将功能升级为“炒菜”，甚至是“制作菜品”等。
结合相关功能，系统性思考和抽象，明确功能的概念，是功能设计的前提。
产出物：更新语言库，更新脑图
3.2 用例的位置
我们在1.3用例分析章节，明确了用例与角色的关系，在1.4领域划分章节，明确了用例与领域的关系。
然而一个新功能的加入，我们仍然要再次评估，以确保他处于正确的位置。按照之前的做法,根据功能相关性确认用例的领域，根据角色相关性确认用例的领域服务。
产出物：更新用例图
3.3 事件风暴
事件风暴常用于梳理业务流程，适用于解构跨领域的复杂业务，感兴趣的朋友可以去自行学习。
但是、对于领域内的单功能，稍有复杂的时候，我们可以采取简化版事件风暴的方法，从而获得如下信息：
将功能拆分为多个子功能（步骤）。（在后续使用）
步骤对应的角色+角色身份。（在后续的3.6章节落地）
步骤的串联流程+领域事件。（在后续的3.6章节落地）
步骤依赖的实体。（在后续的3.7章节落地）
产出物：事件风暴模型
3.4 用例分析
我们暂且收回思路，首先要关注共性和差异问题，以实现功能复用或扩展。
- 确认用例的泛化+差异点，实现功能的扩展。
- 寻找共同包含的步骤，实现逻辑的复用。
产出物：用例分析图
例：制作菜品（做大拌菜、做铁锅炖、做炒鸡蛋、做蒸米饭、做炒米饭）
??
3.5 用例实现类（领域服务类）结构图
首要关注点是领域服务类的结构问题，结构决定了扩展，我们需要先达到“面相修改关闭，面相扩展开放”的目的。
领域服务的类结构图是用例图的映射，服务类结构图反向映射了角色的身份，进一步反向印证了上文的观点。
出物：用例层的类结构图
??
3.6 用例流程图
我们接回思路，更进一步，将事件风暴模型落实到代码层面。
我们将步骤分配到实现类中、步骤就是该类的一个方法，进一步明确由哪个类和方法来实现该步骤，从而就规定了步骤所在的领域服务。再将步骤和领域事件串联起来，规定了业务实现流程。
在确认步骤所在位置的时候，根据角色身份相关性定位步骤的具体实现类。
推荐使用泳道图表达上述内容，泳道的纵向组件是领域服务类，领域服务承接了所有子功能，流程图也需要体现所有的步骤，这是用例层的横向交互。
程序流程就是业务流程的映射，步骤分布体现了角色身份的差异。
产出物：用例流程图
以炒鸡蛋为例，其用例流程图如下
??
3.7 活动图（时序图）
进一步将事件风暴模型落实到代码层面，我们使用时序图，体现依赖和调用关系，规定了步骤与领域实体模型的关系，说明该步骤影响了谁。
时序图体现了领域服务内部的纵向交互，为了简便、我们可以收起领域服务类（用例层）的泳道。
产出物：时序图、活动图
??
在本篇文章中，通过三大步骤阐述了映射办法，让软件系统成为真实业务的说明书，软件系统似乎在对我们说“谁？在哪？做了什么事？影响了谁？是怎么做的？有什么差异？”。例如我们画的圈成为了应用名或包名，圈中的领域模型图成为了实体类+数据模型，圈中的用例图成为了领域服务和方法，功能流程成为了程序调用链，功能步骤成为了方法，领域服务类结构反向体现了角色身份，也体现了不同身份的差异...... 系统就是业务、业务就是系统、两者可以相互映射。
DDD的概念有很多，到底什么是DDD？是思想吗？是方法论吗？每个人都有自己的理解。在我看来、DDD是一套系统化的办法，无法用几句话说清楚，故而以此分享DDD的落地模式。
< class="pgc-img">< class="pgc-img">| 职业餐饮网 王春玲
“饭香、串香、馄饨香”
……
在中国餐饮界里可以称为知名企业的比比皆是，但可以称为“奇迹”的餐饮企业却凤毛麟角！
在餐饮商海沉浮里，有一家餐企可以说堪称奇迹一般存在。
它创业22年来，只在北京开店，不融资、不加盟、也不上市；
在单品盛行的年代里，它却用盖饭+羊肉串+馄饨的“奇葩”组合做餐饮；
在北京开出100家直营店，单店平均日流水30000+，是全国快餐店平均流水的5倍，单店效益，快餐平均效益，外卖效益都做到了全国第一名！
……
但和其它鸡汤励志故事不同，这家餐企创业的前15年都是在踩坑，可以说餐饮行业能踩的坑几乎都踩了一遍，用真金白银堆砌出宝贵经验。
近日，职业餐饮网记者和南城香创始人汪国玉展开了一场对话。
< class="pgc-img">初出茅庐：
小摊起家，靠1块钱羊肉串火遍北京南城！
视角拉回1998年， 王菲和那英的《相约九八》还在街角传唱，没有互联网，也没有手机干扰，胡同里的孩子满街肆意奔跑，我们也都活得很快乐。
这一年，汪国玉开始了自己的餐饮生涯，说是开餐厅，可和大多数餐饮人一样，他连个像样的店都没有。
因为看到电烤羊肉串生意火，就在永定门支起了一个摊子，顾客在外边吃，他在里边烤。
在别人都一味模仿竞争对手的时候，汪国玉就动起了自己的经营小心思，第一个心思就是要给顾客新鲜的食材，每天天不亮就自己蹬着小车进货，现穿现烤的产品立刻受到了顾客们的欢迎；
第二个就是做“性价比”，别人家的烤串卖1.6元，他卖1元，薄利多销，凭借这两点，汪国玉的羊肉串火遍北京南城。
成长烦恼 ：
红利期过遭遇扩张瓶颈，进入长达15年踩坑期！
汪国玉做餐饮的时期，正是中国餐饮粗狂经营时代，单北京市的GDP每年都以10%递增，用他的话来说，那个时期只要吃苦耐劳，闭着眼睛就能赚钱。
随着城市化进程加快，原有的小摊属于占道经营，无法再继续，他想干脆在羊肉串的基础上开一个快餐厅吧。
2001年，南城香第一家餐厅开业，主打产品是电烤羊肉串和馄饨。
你可以看到，只要再加一个盖饭，基本就是今天模式的雏形了，就符合现在的口号“饭香、串香、馄饨香”了。
但事情并不是这么发展的，在那之后，走了很多的弯路，南城香进入了长达15年的踩坑期，主要做了如下动作：
1、无限满足顾客需求，卖过很多种类产品，除了羊肉串、馄饨外，还卖过炒菜、凉菜、面条、小火锅
2、不专注，做副牌，开出唐人乐，类似于“南京大排档”，主卖小吃产品
3、给员工分股权，积极性反而降低
虽然，这些尝试并没有让汪国玉赔钱，甚至还盈利，但问题是，做了这么多尝试，还是在原地打转，开到了20多家店之后，数量再也增长不上去了。
一战成名：
总部减人为一线服务，做14小时全时段快餐生意！
进入2014年，汪国玉决定重新定位，南城香进入变革期！
花钱的(总部人员）服务挣钱的(门店），挣钱的服务给钱的（顾客），自2014年变革之后，南城香保持了每年20多家门店增长速度，营收增长15倍。
变革就是一场硝烟弥漫甚至带有一些血腥味道，也因为变革，南城香一战成名，成为快餐行业平均效益最高的餐饮企业，75平的小店日流水最高可以达到5万元。
对内：组织架构变革
1、从飞机型到飞碟型，精简总部人员，为一线服务
在变革以前，汪国玉形容南城香的组织架构是飞机型架构，看起来很完美，总经理到营运、产品，品牌总监再到区域经理、店长、督导、人力几乎什么都有。
30家门店，总部有40多人，这种架构是十分臃肿的，工作效率很低，从上到下沟通不畅。
于是他顶着巨大压力力排众议，开始大动作砍人，凡是不能创造价值的门部和人员全部砍掉，从40人砍掉只剩下个位数，让总部优秀人员到一线去，当店长，抓经营。
重新搭建组织架构一一＂飞碟型组织架构＂，这种架构总部管理干部变少，在一个平台上，所对应的是一线店长和其它服务部门的平台，把重心放到一线，这样一线人员的积极性就被调动起来了。
在经营中遇到困难和问题可以直接求助总部，总部是服务部门，第一时间帮助解决，工作效率大大提升，门店的营业额也大大提升，所有人的收入也会大大增长。
当然变革也是痛苦的，变革之初总部干部人员减少，很多人思想动摇，认为＂南城香不行了＂。
“今天回想起来，变革或许失败，但不变一定会死。”汪国玉说。
2、改股份制为店长承包制，单店营业额翻10倍
有了“以经营为中心，以门店为中心”的方针思路后，南城香大胆的将过去的股份制改为承包制，店长有决策权，经营权，创新权。
店长的工资结构调整为：基本工资1万+流水提点0.5%+超额任务奖金
拿角门店举例，过去这家店的日流水是4000元，改承包后，店长开始自己想办法，上外卖，营业额一下子涨到了8000—10000元，汪国玉又提出新的要求，能不能再努力往上做做，于是他又开始动脑筋做服务，来门店就餐的就送免费水果……
日流水突破了4万，翻了整整十倍，这个店长也因此一年拿到了几十万元超额任务奖金。
3、激活一线，走计件制，油条工每炸一根油条多赚5毛钱
店长是按照任务给激励，那么一线员工，该如何激发他们的工作热情呢？
南城香选择走计件模式，在基础工资的基础上，多劳多得。
举个列子，早餐中最难做的就是油条，为了鼓励员工炸好油条，每炸一根油条就多给0.5毛钱，所以你会看到员工为了多赚这个钱，拼命炸，拼命做好，做好后还会拼命卖。
生意好的门店，单炸油条工每天都能多拿到上百元钱，羊肉串岗位也是如此。
4、每月5号发钱，取消年终奖，即时奖励
很多餐饮企业都喜欢给员工发年终奖，钱还是那个钱数，可是员工拿起来却不爽。
那为什么不能每月去发，让他们更有感觉呢？
所以，南城香取消了过去的年终奖变为了月度奖励，通过全年倒推月度任务，即时奖励提高员工积极性，同时鞭策未能完成任务的员工。
对外：重新定位
1、做“全时段社区餐饮”，75平门店日流水3万+
现在南城香一个75平的门店日流水是3万+，行业里大多快餐店的日流水是在7000—10000元之间，也就是同等面积，它是别人的5倍。
许多同行看到这组数据都会感到不可思议，这主要归功于它们全时段+社区餐饮的定位。
首先，拿全时段来说，别的快餐厅就中午、晚上两个饭口，营业时长是5-6个小时；
而南城香从早上6点就开始营业、中午、下午、晚上同样营业，一天可以做14个小时生意，比其它快餐多出了近8个小时的生意，8个小时可以多卖多少？
其次，为什么要做社区定位呢？
试想一下，写字楼我们周一到周五上班去，商超六日购物去，只有家是我们每天都回的，所以其它快餐可能只能做周一到周五，或者六日生意，南城香却可以做满一周的生意。
2、三个大单品打天下，饭香、串香、馄饨香
前几年，只要外出，很多定位老师，很多同行都会和汪国玉说：“你们的定位是不对的，三个大单品（馄饨、饭、羊肉串）打天下也太混乱了吧。”
几年过去，南城香依然还是当初的产品定位：饭香、串香、馄饨香
为什么要这样搭配呢？快餐区别于其它餐饮业态，属于一门高频且吃固定客群消费的业态，所以需要产品丰富，但产品丰富不意味乱上产品，既不能太硬，也不能太湿，最理想的产品结构就是“干湿搭配”，比如馄饨是湿的，盖饭是干的，羊肉串定位为休闲产品，消费没负担。
3、学优衣库，只卖经典款不卖“时髦款”
在快时尚行业，有一家企业是汪国玉敬佩的，那就是优衣库。
它的SKU很多却不乱，平价又受欢迎，秘密就是只卖经典款。
放到餐饮行业里也是一样，你会发现米饭类快餐，馄饨，麻辣烫这种存在百年以上的产品业态，不容易被淘汰，反而是一些创新产品容易死掉。
所以，南城香的策略是经典产品长期卖，时髦产品阶段卖。
4、用外卖做第二增长曲线，占比50%
很多人熟悉南城香，是因为南城香的外卖，这里边简单给大家分享两点南城香做外卖的小诀窍：
（1）97家门店，全部设立独立外卖取餐窗口
说到独立外卖取餐窗口，有很多餐饮企业在做，但是做的不彻底，南城香现在所有门店都设独立外卖取餐口，这样的好处是效率提升，堂食的顾客就餐体验也会更好。
（2）13:00后用餐，给外卖小哥打6折
截止到目前，中国外卖小哥的数量已经突破了50万人，是特别庞大的群体，而他们又是我们外卖和顾客最直接接触的人，他们满意，我们的顾客才能满意。
所以，南城香选择在13:00非餐饮用餐高峰给外卖小哥6折，并且外卖慢5分钟以上，就送一瓶可乐道歉。
现在，只要闲时，南城香的门店里就聚集一帮外卖小哥，带来生意的同时也维护了关系，让外卖员和餐厅的关系不再是对立面。
职业餐饮网小结：
做餐饮就是一场“定力”的比拼，南城香一直有着自己的定力，带着警惕之心学习做餐饮。
今天分享的案例，不是让大家看到南城香营收数据有多牛，而是放弃一味模仿，时刻把自己当成探路人勇攀高峰的心，才是真正值得我们学习的。
