培训机构

    北京宙通佳豪科技有限公司是面向IT企业及军工科研生产单位的专业培训咨询机构，公司拥有专业的专家讲师团队，成熟的产品体系，一流的客户服务，凭借在培训领域多年的教学经验和项目经验，针对企业的实际需求提供专业的技术培训、管理培训、咨询服务、项目开发等服务。

         培训目标需求分析人员和领域专家无法与团队的设计人员和开发人员进行有效沟通。需求分析人员不了解软件设计，软件设计人员常常会曲解需求内容，这是软件开发中容易出现的第一病症。它带来的后果是设计频繁变更，设计的软件不满足客户需求。需求分析虽然明白无误，设计人员却无法准确地抽象领域模型，从而不能开展有效的软件设计，这是软件开发中容易出现的第二病症。它带来的后果是设计质量糟糕，开发的代码不具有良好的可读性，增加了软件的开发与维护成本。系统的业务需求复杂多变，设计人员却总是喜欢从实现角度以及数据库层面思考业务问题，这是软件开发中容易出现的第三病症。它会导致开发的系统过于复杂，且可扩展性差，无法有效应对需求发生的变化。本次培训的内容——领域驱动设计正好是解决这三种常见病症的最佳药方。

    专家老师

     张逸老师，宙通佳豪高级专家讲师。先后就职于中兴通讯、惠普GDCC、中软国际、ThoughtWorks等大型中外企业，任职角色为高级软件工程师，架构师，技术总监，首席咨询师。精通包括C#、Java、Ruby、Scala、Python、JavaScript等多种语言，熟练掌握面向对象思想、领域驱动设计、函数式语言、架构、大数据分析、敏捷与过程改进，并致力于大型软件企业的面向服务系统架构设计以及互联网Web系统架构设计。在ThoughtWorks期间，作为一名咨询师，主要为客户提供组织的敏捷转型、过程改进、系统架构监理、领域设计、代码质量提升等咨询工作。目前，作为公司产品的架构师，致力于商业智能产品与大数据分析平台的开发与架构设计。张老师作为主持人或讲师多次被应邀参加如中国软件大会、QCon、MPD大会、Agile China、Scrum Gathering等大型会议，并作为培训讲师曾先后为摩托罗拉、惠普、花旗银行、携程、TCL、中兴通讯、赛门铁克、广发证券、平安银行等企业培训架构、设计、DDD、敏捷等专题内容。著译作包括《软件设计精要与模式》、《Java设计模式》、《恰如其分的软件架构》、《WCF服务编程》、《人件》等。目前，正在撰写《架构之美(Beatiful Architecture)》评注版，即将出版。培训大纲标题

       内容第一单元：为什么需要领域建模 优秀的软件系统与好的软件设计息息相关，但最关键的还是在于对需求的理解。如果不能正确的理解软件需求，那么再好的设计也不能设计出好的软件。正确的做事情固然重要，更重要的是要做正确的事。然而，需求到设计存在巨大的鸿沟，因为需求是站在业务角度来考虑，而设计往往会站在实现角度。领域建模就是为这二者搭建一个沟通与转换的桥梁。本部分概要介绍了领域驱动设计的设计思想，讨论了战略式设计与战术式设计的设计要素。内容包括：* 问题域* 核心领域与子领域* 解决方案域

      第二单元：战略式设计 通用语言（Ubiquitous Language）为了更好的理解需求，我们需要与领域专家一起梳理目标领域的通用语言，从而就领域术语达成一致，并有利于领域建模。本部分将讨论诸多获得通用语言的方法，并给出实例来说明通用语言对模型以及代码的影响。内容包括：* 获得通用语言的方法* 通用语言对编码的影响限界上下文（Bounded Context）若要进行领域建模，并将业务需求逐步演化为架构设计，则需要引入DDD（领域驱动设计）的战略设计作为指导。用户故事地图与限界上下文可以很好地结合，帮助架构师很好地识别各个子领域的概念边界与设计边界。如此则可以运用“分而治之”的思想识别出整个系统的业务逻辑边界与物理边界。本部分同时还讨论了诸多设计原则在Bounded Context中的运用，探讨了Bounded Context的本质思想，强调Bounded Context的边界，进而与微服务架构结合起来，即Bounded Context的设计其实就是微服务的设计。内容包括：* Bounded Context的意义* 识别Bounded Context* 议题：Bounded Context的边界上下文映射图 (Context Map)本部分内容会讲解限界上下文之间主要存在的组织模式与集成模式，这其中包括防腐层，开放服务调用等。利用上下文映射图，有助于识别上下文之间的关系，思考处于上下文内领域模型之间的通信方式，从而帮助架构师驱动出最终的应用逻辑架构。内容包括：* 团队的组织模式* 集成模式* Context Map案例分析架构模式分层架构 (Layered Architecture)分层架构模式是应用最为广泛的架构模式，它根据关注点分离的架构原则，针对表现层、领域层和基础设施层进行层次分离。本次培训将以全新视角审视分层架构，针对大型软件系统分析该如何进行分层架构设计。内容包括：* DDD分层架构模式* Clean Architecture思想* 依赖注入与贫血模型六边形架构 (Hexagonal Architecture)虽然分层架构仍然是运用最为广泛的架构模式，同时更是诸多架构模式的基础，但它已不足以描述越来越复杂的分布式系统架构。由Cockburn提出的六边形架构（Hexagonal Architecture）是一种具有对称性特征的架构风格。在这种架构中，不同的客户通过“平等”的方式与系统交互。该架构中存在两个区域，分别是“外部区域”和“内部区域”。这种界定了明确内外边界的架构风格，更有利于架构师实现关注点分离，并将关注重心放在适配器与通信端口上。CQRSCQRS风格，即命令查询职责分离（Command Query Responsibility Segregation），它结合了消息处理、事件处理的架构风格，是对多种设计模式的综合运用，适用于处理读写比例高，需要支持可伸缩性的大型系统。事件驱动架构 (Event-Driven Architecture)事件驱动架构（Event-Driven Architecture，EDA）是一种用于处理事件生成、发现和处理等任务的软件架构。事件往往对应于软件系统的状态机，状态的迁移就是用事件来触发的。因而，事件能够很好地体现这样的业务模型。同时，基于事件的软件架构可以帮助我们更好地建立松散耦合的模块化架构。         第三单元：战术设计 领域建模通过限界上下文，可以帮助我们分析系统的领域模型，包括系统的核心领域与子领域。确定系统的核心领域与子领域可以帮助架构师合理分配资源（包括时间资源与人力资源）。而对子领域的进一步识别，可以帮助架构师更好地识别可重用资源，包括可重用的功能模块，确定技术栈，决定构建还是购买的架构战略。本部分将讲解DDD中的核心概念，并引入四色建模来帮助我们进行领域建模。内容包括：* DDD中的核心要素* 运用四色建模法* 领域模型的演进实体与值对象这两个概念都是领域对象的体现，二者的主要区别在于对“标识”的运用。本部分的内容深入展开对实体标识的讨论，揭示实体的本质特征，挖掘实体的关键行为。通过识别角色与职责对实现进行分析。本部分内容还将通过深入讲解值对象的特征帮助我们分辨值对象与实体，使得我们可以在领域驱动设计中有效地运用实体与值对象。本部分内容还包括持久化值对象，以及领域驱动设计与ORM之间的关系。内容包括：* 实体的标识* 避免贫血模型* 角色、职责与协作* 领域建模与数据建模领域服务通过讲解什么是领域服务，什么不是领域服务理清领域服务的概念，并讲解如何建模领域服务。讨论领域服务和面向接口设计思想。内容包括：* 何时建模为服务* 识别建模的坏味道聚合 聚合是领域驱动设计最为重要的领域概念。本部分内容将深入探讨聚合的设计原则，并辨别在聚合设计中可能出现的坏味道，并提出针对性的解决方案。这些原则和方案包括：在一致性边界之内建模真正的不变量，设计小的聚合，通过唯一标识引用其他聚合，在边界外满足最终一致性。内容包括：* 聚合维护多个实体、值对象的边界* 案例研究* 设计聚合的原则工厂和资源库工厂和资源库都是管理领域对象（实体、值对象和服务）生命周期的对象。工厂主要针对内存中对象从无到有的创建过程，与设计模式的工厂模式基本相似。资源库则分为面向集合的资源库与面向持久化的资源库。本部分内容将重点讲解与资源库直接相关的技术细节，包括如何选择资源库的方式，如何针对聚合持久化资源库，如何管理事务，以及分辨资源库与数据访问对象（DAO）之间的异同。领域事件 事件驱动架构的主要对象即为领域事件，我们要分清在何时以及为什么要使用领域事件，并对领域事件进行建模。通过讲解发布者-订阅者模式讲解如何在领域模型和限界上下文中发布领域事件。同时，针对事件进行存储的Event Source也与CQRS架构风格直接相关。内容包括：* 事件的本质* 事件带来的价值应用层设计作为为UI提供的应用服务，其目的在于管理和协调领域对象，并为领域对象提供横切关注点的内容。好的应用服务设计不应该承担任何与领域逻辑有关的职责。应用层是架构层面的外观与适配器模式的体现。它可以提高软件系统架构的可用性与简单性，也能够更好地与面向服务架构或RESTful架构风格结合。时序图根据事先识别的Use Case，为其绘制时序图，动态地寻找Application Service到各种领域对象之间的协作，以帮助我们寻找到遗漏的领域对象与设计对象。

        第四单元：DDD实战演练 项目需求：企业应用套件（EAS）系统是一个根据某集团应用信息化的要求而开发的企业级应用软件。本系统为用户提供大量简单，快捷的操作接口，集团相关部门能更快捷、更方便、更高效地处理日常事务工作，并为管理者提供决策参考、流程简化，建立集团与各部门、员工之间交流的通道，有效地提高工作效率，实现整个集团的信息化管理。项目目标实现集团企业应用信息化，包括人力资源信息管理、项目管理、客户关系管理等。具体目标如下： * 实现集团日常事务的信息化管理，包括工作日志、考勤、月度工作评价等； * 解决客户业务需求与集团人员供应之间的矛盾，实现供需平衡，建立沟通的有效通道； * 实现项目的信息化管理，包括项目开发流程管理、项目人员信息跟踪、统计项目信息等； * 提供市场信息、人员信息、项目信息的统计，辅助管理者作出正确的决策。项目要解决的问题：Ø 公司市场信息、人员信息不畅通，无法实现人员供需平衡：“供”主要表现在各公司富余人员信息、项目中快结束人员信息、人员招聘信息、学院培训人员信息等不能有效反馈。“需”主要表现在已签约项目人员需求、意向项目人员需求、公司计划人员需求等信息无法及时传递。“供”“需”脱节，信息不畅，不能快速有效的进行供需求匹配。Ø 公司各项配套管理问题。各职能部门不能及时获得“供需”信息，也就无法及时对设备、住房、工位、资金进行配套协调管理。Ø 辅助决策管理问题。公司领导决策层不能很好的把握全局，无法有侧重的进行资源协调及工作支持，包括市场力度、人才管理、财务政策及公司日常管理。Ø 客户信息共享及项目管理质量控制问题。无法跟踪项目人员的工作状态，可能导致项目组成员以及项目质量的失控。这是领域驱动设计过程的完整案例分析，从需求开始着手，开展对整个系统的架构分析、领域概念识别与分析，并对建立的领域模型进行迭代与演化，核心领域概念的演进，扫清领域设计过程中的认知障碍，并总结了领域驱动设计过程的一些经验教训。本实战演练包含了真实的案例需求，以及符合领域驱动设计各种知识点的案例病症分析，从对比入手来探讨好的领域驱动设计方法。同时，还将引入大量的可视化图形、设计图与代码帮助学员理解如何在真实项目中运用领域驱动设计的思想，指导设计人员进行良好的设计。