入門 境界づけられたコンテキストphperkaigi 2022の資料です。 理解しながら共通化するところはするなどいいバランスを心がけましょう。 音声が悪いですが資料だけでなく、トーク内容も併せて・・！
初転職4年間のまとめ、あるいはCTOを辞めたお話 - 考えた。
4年間務めた株式会社セプテーニ・オリジナル、およびコミックスマート株式会社を退職しました。役職はどちらもCTOでした。どなたかの役に立つことを願い、4年間の活動とその結果をまとめます。2014年。開発組織を作るためにやってみた事 と 2015〜2016年で開発組織を作るためにやってみたこと を最新結果と共にまとめた物になります。 前提：自分は何をやりたかったのか "高速で高品質な開発ができる組織を作りたかった"が一つ。これは前のエントリ技術的負債について考えたで詳しく述べています。 もう一つは "有名プロダクトも知名度もない会社で腐った開発をしてたら、採用ができないよの解決"です。採用は会社の生存には欠かせない重要な要素ですが、エンジニアにはセプテーニの知名度はほぼありませんし、GANMA!等を除けば基本的に社内向けのツール開発になります。その上で開発文化も残念な状態になってしまってはエン
現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法
2017年7月5日紙版発売 2017年7月5日電子版発売 増田亨 著 A5判／320ページ 定価3,234円（本体2,940円＋税10%） ISBN 978-4-7741-9087-7 Gihyo Direct Amazon 楽天ブックス honto ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle ブックライブ 楽天kobo 本書のサポートページサンプルファイルのダウンロードや正誤表など この本の概要 「ソースがごちゃごちゃしていて，どこに何が書いてあるのか理解するまでがたいへん」「1つの修正のために，あっちもこっちも書きなおす必要がある」「ちょっとした変更のはずが，本来はありえない場所にまで影響して，大幅なやり直しになってしまった」といったトラブルが起こるのは，ソフトウェアの設計に問題があるから。日本最大級となる60万件以上の求人情
ドメイン駆動設計について DroidKaigi 2017 で登壇しました。
長らく Y.A.Mの雑記帳というブログでAndroidの技術情報を発信しています。最近はなかなか投稿できなくなってしまいましたが、それも仕事としてAndroidに関われているためです。Androidを触り始めたころはまだ学生だったので時間があったんでしょうね。 はじめて Android に関するエントリを投稿したのは 2009 年 5 月 24 日です。当時はJavaFXを触っていたので、NetbeansでAndroidをやろうとしていたようです。 当時のAndroidのバージョンは1.5、Fragment もなく、Support Library もなく、マルチタッチすらなく、ストアは Google Play ではなく Android Market という名前でした。 ここから2、3年くらいは、仕事でAndroid アプリを開発している人はもっぱらメーカーのプリインアプリを作っている方たち
わかる！ドメイン駆動設計 ～もちこちゃんの大冒険～【C91新刊】 - TechBooster - BOOTH
【C91新刊（電子書籍）】 わかる！ ドメイン駆動設計～もちこちゃんの大冒険～（A5相当で60p）はソフトウェア設計手法であるドメイン駆動設計（DDD）の解説書です。 DDDの原書である「エリック・エヴァンスのドメイン駆動設計」はたいへん分厚く、読み応えがある内容です。 そこでDDDを理解する手助けに（すべてを解説するのではなく）入門に必要な知識をわかりやすく、物語を通じて理解できる構成にしました。 主人公の「もちこちゃん」はモバイルエンジニアであり、いろんな人の手を借りながらソフトウェアモデルを設計していきます。道中にもちこちゃんが出会った問題は、どんなエンジニアでも遭遇する共通の課題です。本書を読むことでチームでの開発指針を定めたい、プロジェクトの見通しを良くしたいなど複雑化したソフトウェア開発を良くしていく活動への示唆となれば幸いです。 もちこちゃんの冒険が今から始まる。 【電子書籍
ドメイン駆動設計の道標 - sandbox
この記事は 2016年 第2のドワンゴアドベントカレンダー、20日目の記事です。 qiita.com ドメイン駆動設計に関して悩める若者に送るポエムを書いていたら長くなりました。 20日目なはずなのに今日は 12/25 ですが、お察しください。 TL;DR ドメイン駆動設計には3つの顏がある それは「哲学」「戦略」「戦術」である 「戦術」にスポットがあたりがちだが、まず「哲学」とコアの「戦略」から理解する プロダクトにおけるドメインモデルの全体像を描いてから「戦術」を検討しよう ドメイン駆動設計をどの程度取り入れるかの 「ドメイン駆動設計の適用レベル」について はじめに ドメイン駆動設計(DDD)、以前と比較して認知が上がってきたのか、よく「DDD やってるんですか?」 「DDD ってどうはじめればいいんですか?」と聞かれることがあります。そしてこの時にまず話に上がるのが、エンティティ、集
苦悩と喜びを与えてくれた[エリック・エヴァンスのドメイン駆動設計]をまとめた - Qiita
はじめに [エリック・エヴァンスのドメイン駆動設計]この本をエンジニアであれば聞いたことや見たことある方はいるのではないでしょうか？ 私も良本という噂だけは知っていたので、一度は読んで読んでおきたいなと思い今回読みました。 私の性格的に、サーっと流し読みはできない性格(流し読みしたところに良いことが書いてあると勿体無いので)なので、しっかりと１文字づつ読んでます。 読んで見て思ったことは、はっきり言って難しすぎる、それなりに設計に関わる技術書は読んでますが、飛び抜けて難しいです。 言い回し、例題、語彙、全てにおいて難しいです。少しでも気を抜くと何言っているのか分からなくなります。 全く中身のないことを、それっぽく言っているだけなのではないかと錯覚をするほどです。 このTED Talksを思い出しました。 [ウィル・スティーヴン 「頭良さそうにTED風プレゼンをする方法」] https://
![苦悩と喜びを与えてくれた[エリック・エヴァンスのドメイン駆動設計]をまとめた - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/e8f2472ae2689116e8e3986529f8139da3c85463/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JUU4JThCJUE2JUU2JTgyJUE5JUUzJTgxJUE4JUU1JTk2JTlDJUUzJTgxJUIzJUUzJTgyJTkyJUU0JUI4JThFJUUzJTgxJTg4JUUzJTgxJUE2JUUzJTgxJThGJUUzJTgyJThDJUUzJTgxJTlGJTVCJUUzJTgyJUE4JUUzJTgzJUFBJUUzJTgzJTgzJUUzJTgyJUFGJUUzJTgzJUJCJUUzJTgyJUE4JUUzJTgzJUI0JUUzJTgyJUExJUUzJTgzJUIzJUUzJTgyJUI5JUUzJTgxJUFFJUUzJTgzJTg5JUUzJTgzJUExJUUzJTgyJUE0JUUzJTgzJUIzJUU5JUE3JTg2JUU1JThCJTk1JUU4JUE4JUFEJUU4JUE4JTg4JTVEJUUzJTgyJTkyJUUzJTgxJUJFJUUzJTgxJUE4JUUzJTgyJTgxJUUzJTgxJTlGJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz04N2VlODU5NWQxMTZkNGUxZDYyNWVkODBiMWFiMzRjNg%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBrb2l0YXJvJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1iNTZiOTk5NTcwNmIxMzAyMGU5YzU3MzQzZjA2ZmJkMQ%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-44Ki44Kk44K544K_44Oz44OA44O844OJ%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3D915d3d794d8a86ab6b01ad26d6984695)
クリーンアーキテクチャ(The Clean Architecture翻訳)
Robert Martin (a.k.a. ボブおじさん) による、 The Clean Architecture の翻訳です。似たようなアーキテクチャである ヘキサゴナルアーキテクチャ も翻訳したので参考にしてください。 この記事を翻訳して公開したことは 8th Light, Inc. に報告済みです。いまのところ苦情は来ていません。 ここ数年以上、システムのアーキテクチャに関する実にさまざまなアイデアを見てきた。これには、次のものが含まれる: Hexagonal Architecture (別名 Ports and Adapters) by Alistair Cockburn。Steve FreemanとNat Pryceが、Growing Object-Oriented Software というすばらしい本で採用した。 Onion Architecture by Jeffrey Pa
ヘキサゴナルアーキテクチャ(Hexagonal architecture翻訳)
Alistair Cockburn による Hexagonal architecture の翻訳です。PoEAAで言及されていることから、2002年ごろにはすでにC2 Wikiにページがあった模様。似たようなアーキテクチャである クリーンアーキテクチャ も翻訳したので参考にしてください。 この記事は著者から許可を得て公開しています。Thanks to Alistair Cockburn! 目次 パターン: Ports and Adapters (構造に関するパターン) 意図 動機 解決法の本質 構造 サンプルコード ステージ1: FIT アプリ 定数をモックデータベースとして ステージ2: UI アプリ 定数をモックデータベースとして ステージ3: (FITまたはUI) アプリ モックデータベース 応用ノート 左右の非対称性 ユースケースとアプリケーションの境界 ポートはいくつ? 既知の用
ドメイン駆動設計と関数プログラミングをScalaで - Qiita
はじめに この記事は Scala Advent Calendar 2016 - Qiita の 7 日目の記事です。 私事で恐縮ですが、今年の個人的なハイライトは、遅まきながらドメイン駆動設計と関数プログラミングを学べたことでして、その中でも、"Functional and Reactive Domain Modeling" (Debasish Ghosh 著) (以下、FRDM本) を読んで、ふたつのコンセプトが自分の中で繋がったことが最も大きなものでした。 Manning | Functional and Reactive Domain Modeling この記事では、本書の紹介も兼ねて、ドメイン駆動設計がどのように関数プログラミングと結びつくのか、非常にざっくりではありますが、Scala で表現してみたいと思います (ちなみに、私の Scala 歴は3ヶ月ほどですので、サンプルコード
DDD体験ワークショップに参加してきました - かまずにまるのみ。
PHPカンファレンス2013 で PHPメンターズ さんの『モデルとの向き合い方：ドメイン駆動設計体験ワークショップ』に参加してきました。 PHP メンターズさんの記事と資料はこちらに掲載されています。 http://phpmentors.jp/post/61286646859/phpcon2013-ddd-workshop ドメイン駆動設計って？ そもそもドメイン駆動設計とは何なのか。 ドメイン駆動設計（DDD）はビジネスドメインの概念をソフトウェアという人工物にマッピングすることです。 ドメイン駆動設計・開発の実践 上記引用元にも出ている Eric Evans 氏の書籍は 「エリック・エヴァンスのドメイン駆動設計」というタイトルで日本語版が出版されています。（この書籍については以降 DDD 本と表記） 500ページ超とそこそこボリュームはありますが、読みやすい本だと思います。 気になっ
[iOS] 条件分岐を減らして、処理をシンプルにする - Qiita
はじめに ①ViewControllerから処理の一部を切り出したい → ViewControllerの肥大化 ②ViewControllerで状態（フラグ）を意識したくない → フラグ管理がカオス ③ユニットテストしやすくしたい → テスト容易性 上記の課題を解消する一つの方法をご紹介します。 その答えは、「条件分岐を減らす」です。 環境 XCode : 8.0 Swift : 3.0 今回ご説明する例 今回は、下記のようなシンプルな例で説明します。 ①ログオフ状態の場合、ログインボタンを表示する（フォントカラーは青色） ②ログイン状態の場合、ログアウトボタンを表示する（フォントカラーは赤色） 1. Badケース まず最初にBadケースをご紹介します。 ViewController内でログイン状態を意識し、 ログインとログオフで処理や表示に違いがある度に、 条件分岐が増えてしまいます。
![[iOS] 条件分岐を減らして、処理をシンプルにする - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/ee268d837000625bbf3bc55e52866bdf6e7b48c1/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCaU9TJTVEJTIwJUU2JTlEJUExJUU0JUJCJUI2JUU1JTg4JTg2JUU1JUIyJTkwJUUzJTgyJTkyJUU2JUI4JTlCJUUzJTgyJTg5JUUzJTgxJTk3JUUzJTgxJUE2JUUzJTgwJTgxJUU1JTg3JUE2JUU3JTkwJTg2JUUzJTgyJTkyJUUzJTgyJUI3JUUzJTgzJUIzJUUzJTgzJTk3JUUzJTgzJUFCJUUzJTgxJUFCJUUzJTgxJTk5JUUzJTgyJThCJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0yYzE2ZTNmYWYxZTQ4OTgwZGZhZDBhOTkxN2NlM2FkZQ%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwZUt1c2hpZGEmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTEwOTZkNDA1ZGY3NDFjYTNjYTAwMTFmYzJhMjYzMmRl%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D5cadaebc0ab6d59ef088b84875d977d2)
持続可能な開発を目指す ~ ドメイン・ユースケース駆動（クリーンアーキテクチャ） + 単方向に制限した処理 + FRP
この記事は、開発を持続可能にできるようなアーキテクチャとその適用方法を考察するものです。 骨子はできていますが、実装経験をフィードバックして詳細を若干変更するかもしれません。 勉強不足な点もあるので、意見を歓迎します。 開発においてよくある問題点 ビジネスロジックの本質が何だったか見失う。ソースコードのどこまでが業務上の関心で、どこからがそれを実現するための技術上の関心か分からなくなる。 入出力双方向の処理が散在して処理が追い切れなくなる。特にイベント処理でどこに飛ぶかわからないコールバック地獄になる。 初期化・つなぎ込み・統合者的オブジェクトが小さな機能単位で生まれて統一感が無くなる。 状態を持つ値が大量に散在して副作用を起こしバグを生む。 これらの問題の結果、小さな単位ごとに個人のノウハウで"良い"設計がされ、機能を追加しようとしたときにどういう方針で行えばよいか分からなくなる。 解決
【Swift】DDDを取り入れたiOS開発 その1 ~UseCaseとdelegate~ | Recruit Tech Blog
この記事は RECRUIT MARKETING PARTNERS Advent Calendar 2015 の投稿記事です。 こんにちは。英語サプリのiOS担当の大島です。英語サプリは10月末にリリースしたばかりのサービスで、アニメーションやBGM・効果音を取り入れたゲーム感覚の英語学習アプリです。iOS版とWeb版がリリース済みでまだサービスは始まったばかりですが、開発期間も短い中でクオリティにこだわってローンチすることが出来ました。当エントリでは、iOSアプリケーションの設計手法について紹介していきたいと思います。 DDD（ドメイン駆動設計）で複雑さと戦う 複雑なiOSアプリケーション開発をしていると以下のような問題点で悩まれているエンジニアの方も多いのではないでしょうか。 すぐにFatになってしまうUIViewController 複数のフラグで状態を管理するUIViewContro
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ドメインもしくはドメインモデルという概念が登場する書籍一覧
20110409_DevLOVE「実践！ ドメイン駆動設計」_増田亨さん
Eric Evans氏: ドメイン駆動設計は、以前より以上に妥当性を獲得している
ドメイン駆動設計基礎講座〜戦略編〜
ドメイン駆動設計入門
InfoQ: Domain Driven Design（ドメイン駆動設計） Quickly 日本語版